Системное время отключено до сотен миллисекунд, несмотря на синхронизацию NTP перед загрузкой

Я использую пару серверов, которым требуется довольно жесткая синхронизация времени (<50 мс), поскольку они используют алгоритм Paxos. Серверы работают по протоколу NTP и успешно синхронизируются в одной точке. В соответствии с hwclock включен 11-минутный механизм, поэтому системное время следует скопировать на аппаратные часы.

Тем не менее, я вижу, что после перезагрузки системное время может быть отключено на целых 300 мс по сравнению со временем перед перезагрузкой. Разумно ли думать, что после перезагрузки время должно быть в пределах 50 мс от времени непосредственно перед перезагрузкой?

Источник

2 ответа

У меня нет чисел для производства, но кажется вероятным, что интерфейс, используемый для установки часов при загрузке, имеет точность только с точностью до секунды.

Вы не указываете свою ОС, но на всех Unix-подобных системах можно вставить зависимость от времени NTP в процесс загрузки.

Демон NTP запускается при загрузке, но часто он сразу же завершает фоновую работу, и загрузка продолжается, пока демон NTP ищет серверы для синхронизации - это так, чтобы загрузка не задерживалась, если компьютер не подключен к сети.

В этом случае вы захотите убедиться, что демон ntp запущен таким образом, что исправит смещение, шагнув при загрузке. Это может быть, например, ntpd -gx или же chronyc -q, Возможно, вы также захотите вставить проверку того, что смещение приемлемо, прежде чем начинать работу.

Источник

Моя первоначальная реакция заключалась в том, что 300 мс кажутся ужасными, но у меня есть цифры, которые нужно произвести, и они показывают, что @Law29 прав:

  1. Одна из моих машин за нормальную неделю:
    • Частота:
    • Системное одноранговое смещение:
  2. Та же система, более короткий период с перезагрузкой:
    • Частота:
    • Системное одноранговое смещение:
    • Разброс сюжета пэров

(Надеюсь, вы можете прочитать все цифры на графиках ОК - напишите мне комментарий, если нет.)

Как видите, расхождение довольно большое. Меня удивило, сколько это стоило, а также сколько времени потребовалось, чтобы вернуться на правильный уровень с коррекцией частоты, учитывая, что в моей локальной сети есть источник GPS уровня 1. И, учитывая, что одноранговые выборки довольно плотно сгруппированы на графике, это явно проблема с локальными часами, а не несогласованная задержка сети во время запуска. ( Напомним, что аппаратным обеспечением является мини-ПК Shuttle DS437 без вентилятора с двухъядерным процессором Celeron 1037U с частотой 1,8 ГГц.)

Таким образом, вынос, вероятно, являются:

  1. убедитесь, что ntpd успешно записывает дрейфовый файл NTP,
  2. убедитесь, что 11-минутный таймер ядра для обновления аппаратных часов включен (см. "Автоматическая аппаратная синхронизация часов ядром" в man hwclock для деталей), или ваш процесс выключения обновляет аппаратные часы,
  3. убедитесь, что ntpd имеет 4-10 доступных источников (в режиме iburst), и
  4. Сконфигурируйте зависимости при запуске, чтобы у ntpd была возможность установить время до запуска Paxos.
Источник
Другие вопросы по тегам