Eu tenho um servidor remoto não-tripulado que tem exibido um comportamento de relógio / NTP extremamente estranho ultimamente. Sintomas:
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
Do servidor NTP local (ou seja, a máquina em execução no mesmo local físico):
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
Você pode ver que esse servidor NTP local tem bom alcance e jitter relativamente baixo, apesar de estar em uma rede sem fio de alta latência.
Eu modifiquei o minpoll e o maxpoll para valores baixos (4, 5) na máquina primária para que o ntp seja executado com mais freqüência e essa solução "bandaid" parece manter a máquina principal um pouco amarrada à realidade (diferente de antes estava passando minutos a fio várias vezes por dia), mas eu gostaria de chegar à raiz desse comportamento estranho.
Eu tenho uma teoria de que o clock do tsc pode estar à deriva, mas não tenho nenhuma evidência disso. Isso explicaria a alta instabilidade, e isso, por sua vez, poderia talvez introduzir algum comportamento estranho no NTP.Independentemente disso, eu não entendo porque o refid continua revertendo para 'LOCAL (0)' quando este claramente não é o caso. O serviço NTP não está reiniciando. Por exemplo:
● 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
mas observei vários casos dessa reversão para 'LOCAL (0)' nas últimas horas, portanto, não é como começar do zero e precisar de tempo para inicializar ou coletar os dados corretos.
Tags ntp clock-synchronization