У меня есть удаленный беспилотный сервер, который в последнее время демонстрирует очень странное поведение часов / NTP. Симптомы:
admin@machine:~$ date && ntpq -pn Thu 24 May 19:34:02 UTC 2018 remote refid st t when poll reach delay offset jitter ============================================================================== <local_ntpserver> LOCAL(0) 15 u 120 128 377 0.120 -486.68 909.283 admin@machine:~$ date && ntpq -pn Thu 24 May 19:38:37 UTC 2018 remote refid st t when poll reach delay offset jitter ============================================================================== <local_ntpserver> <remote_ntpserver> 3 u 1 128 377 0.123 -1854.0 2164.83
С локального NTP-сервера (т. Е. Машины, работающей в том же физическом месте):
remote refid st t when poll reach delay offset jitter
==============================================================================
<remote_ntpserver> <remote_ntpserver2> 2 u 49 64 377 5076.18 1546.21 299.468
Вы можете видеть, что этот локальный NTP-сервер имеет хороший охват и относительно низкий уровень джиттера, несмотря на то, что он находится в беспроводной сети с высокой задержкой.
Я изменил minpoll и maxpoll на низкие значения (4, 5) на основной машине, так что ntp работает чаще, и это «бандажное» решение, похоже, держит основную машину в некоторой степени привязанной к реальности (в отличие от того, где раньше она дрейфовала минут несколько раз в день), но я хотел бы разобраться в корне этого странного поведения.
У меня есть теория, что часы tsc могут дрейфовать, но у меня нет доказательств этого. Это объяснило бы высокий джиттер, а это, в свою очередь, могло бы привести к некоторому странному поведению в NTP.
Тем не менее, я не понимаю, почему refid продолжает возвращаться к «LOCAL (0)», когда это явно не так. Служба NTP не перезапускается. Например:
● ntp.service - LSB: Start NTP daemon
Loaded: loaded (/etc/init.d/ntp)
Active: active (running) since Wed 2018-05-23 15:58:50 UTC; 1 day 3h ago
но за последние несколько часов я наблюдал многочисленные случаи этого возврата к «ЛОКАЛЬНОМУ (0)», так что это не похоже на то, чтобы начинать с нуля и нужно время для инициализации или сбора правильных данных.