ntpd сам по себе неправильно обновляет дрейф
Думаю, это было достаточно легко проверить. После запуска 5-минутного сна я приостановил работу системы примерно на 2 минуты. Ответ?
Сон рассчитывается с использованием истекшего времени процесса, а не часов.
date; sleep 300; date
Tue Jul 2 20:58:41 EDT 2019
Tue Jul 2 21:05:28 EDT 2019
Это могло быть предсказуемо, поскольку человек спит (3 )говорит:
System activity may lengthen the sleep by an indeterminate amount.
Что подразумевает, что количество времени является внутренним для процесса сна.
По какой-то причине часы вашей операционной системы очень неточны. Обычно ntpdподдерживает правильное время, поворачивая его, т.е. приказывает медленным часам «ускориться», чтобы они догнали реальное время, регулируя только скорость часов, чтобы она соответствовала реальному времени. когда они на самом деле синхронизированы с реальным временем, а также замедляют часы, если они идут слишком быстро.
Но для часов вашей операционной системы эта настройка кажется недостаточной. :ошибка настолько велика, что ntpdприходится прибегать к пошаговой настройке, по сути, переустанавливая системные часы для корректировки времени каждые несколько минут. Если вам нужен точный хронометраж для баз данных и т.п., следует полностью избегать пошаговых корректировок. Вы должны не быть довольны любым не -нулевым количеством ступенчатых регулировок.
К счастью, ошибка, кажется, всегда в одном и том же направлении, так что это может быть систематическая ошибка, которую можно скорректировать.
Примечание.:если это виртуальная машина, дрейф времени может быть вызван тем, что узел виртуализации работает с высокой нагрузкой, и «краже времени» у бездействующих виртуальных машин для запуска занятых. Если это так, сначала обратитесь к администратору хоста виртуализации за рекомендациями по исправлению хронометража :. Может быть параметр «паравиртуализированные часы», который позволит виртуальной машине использовать часы хоста для хронометража, или другие решения, рекомендованные хост-поставщик операционной системы/гипервизора.Просто убедитесь, что хост виртуализации не возится с часами виртуальной машины, если вы пытаетесь использовать синхронизацию NTP :, это одно или другое, а не оба!
Обратите внимание, что hwclock -w --update-driftоценивает дрейф часов RTC с питанием от батареи -, сравнивая их с часами операционной системы, которые в вашем случае уже известны как весьма неточные. Таким образом, вы будете настраивать, возможно, -хорошие часы, чтобы они соответствовали известным -плохим часам, что не кажется хорошей идеей.
adjtimexconfig, с другой стороны, предполагает, что RTC с питанием от батареи -является правильным, и настраивает параметры часов ОС, чтобы они соответствовали этому. Если у вас есть доступ к известному -хорошему источнику времени NTP, вы должны вместо этого использовать adjtimex --host <NTP server>для сравнения часов ОС непосредственно с сервером NTP (, останавливая ntpd, пока вы это делаете ), а затем используйте adjtimex -p, чтобы просмотреть полученные значения frequencyи tick.
В качестве альтернативы вы можете просто использовать adjtimex -p, чтобы увидеть, какое значение смещения frequencyбыло установлено с помощью ntpd. ntpdбудет регулировать только значение frequency; это вообще не коснется настройки tick.
Если вы обнаружите, что значение смещения частоты дошло до любого конца шкалы +/ -32768000, вам следует отрегулировать значение tickвручную, а затем повторить процесс.
(Если frequencyдостигает или приближается к максимальному положительному значению, инструмент пытается ускорить ход часов, но не может достаточно ускорить их, поскольку выходит за пределы диапазона регулировки. Чтобы это исправить, увеличьте значение tick. Если frequencyприближается к отрицательному пределу, уменьшите значение tick.)
Как только вы найдете значение tick, которое позволяет значению смещения частоты оставаться относительно около середины шкалы (, скажем, +/ -5000000 или около того ), тогда у ntpdдолжно быть гораздо больше шансов сохранить синхронизацию часов путем настройки значения смещения частоты по мере необходимости.Вы должны отредактировать значение тика вручную в /etc/default/adjtimexconfigи убедиться, что adjtimex.serviceуспешно выполняется при загрузке :, он запускается до запуска ntpd, и поэтому устанавливает часы ОС в «правильную передачу» до ntpdначинает действовать как «круиз-контроль» для него.
Как только вы получите контроль над часами ОС, так что ntpdбудет оставаться в синхронизированном состоянии(ntpq -npбудет отображаться звездочка в первом столбце )и в журнале не будет сообщений о пошаговых корректировках, кроме, возможно, одного раза. во время загрузки, вы можете использовать hwclock -w --update-driftдля оценки скорости дрейфа часов RTC. Конечным результатом должна быть система, которая показывает точное время, насколько это разумно достижимо, независимо от того, включена она или нет.
А... может, adjtimexconfigи был ответом?! Какой бы ни была причина, то, что я сделал выше, в конце концов заставило ntpdзаписывать обновления в /var/lib/ntpsec/ntp.drift; и за последние 60 минут я получил только два сообщения:
Mai 22 15:59:45 services ntpd[13428]: CLOCK: time stepped by 0.241656
Mai 22 16:31:47 services ntpd[13428]: CLOCK: time stepped by 0.532398
Думаю, пока я доволен этим.
РЕДАКТИРОВАТЬ :Благодаря telcoM я думаю, что теперь у меня есть все ответы и решение. Во-первых, объяснение случившегося :10000, по-видимому, исходное tick. В моей системе это слишком медленно. Так что ntpdприходилось постоянно шагать по времени. ntpне регулирует tick, а только тонкую -детальную настройку frequency, поэтому она ограничена и бессильна, если tickдалеко.
Когда я использовал adjtimexconfig, он зафиксировал tick, но только в соответствии с моим также неточным RTC. Он установил tickна 10031, что все еще слишком мало, поэтому ntpdвсе же пришлось увеличить время. И именно по этой причине /var/lib/ntpsec/ntp.driftостался на уровне 500.000000 (и поэтому ntpd, казалось, никогда не обновлял его ), что эквивалентно частоте дрейфа 32768000 (*65536 ).
Теперь я использовал adjtimex -t 10038для исправления tickи неожиданно перестал видеть сообщения CLOCK: time stepped. ntpdв настоящее время использует frequency: -10025033, поэтому я думаю, что я мог бы использовать и 10037.