Quais são os possíveis motivos para a sincronização irregular do NTP?

Question

Em um sistema Ubuntu 10.04 eu notei após estranhos eventos de sincronização NTP:

Jul  3 02:19:51 hst ntpd[1432]: no servers reachable
Jul  3 02:36:55 hst ntpd[1432]: synchronized to 91.189.94.4, stratum 2
Jul  3 02:53:48 hst ntpd[1432]: time reset -10.407942 s
Jul  3 02:53:48 hst ntpd[1432]: kernel time sync status change 6001
Jul  3 02:53:48 hst dovecot: dovecot: Fatal: Time just moved backwards by 10 seconds. This might cause a lot of problems, so I'll just kill myself now. http://wiki.dovecot.org/TimeMovedBackwards
Jul  3 02:58:37 hst ntpd[1432]: synchronized to 91.189.94.4, stratum 2
Jul  3 02:58:37 hst ntpd[1432]: kernel time sync status change 2001
Jul  3 03:08:15 hst ntpd[1432]: no servers reachable
Jul  3 03:16:49 hst ntpd[1432]: synchronized to 91.189.94.4, stratum 2
Jul  3 03:17:01 hst CRON[28221]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Jul  3 03:18:04 hst ntpd[1432]: time reset +10.403648 s
Jul  3 03:22:41 hst ntpd[1432]: synchronized to 91.189.94.4, stratum 2

Onde 91.189.94.4 europium.canonical.com e a única linha do servidor em ntp.conf são:

server ntp.ubuntu.com

A atualização às 2:36 parece muito falsa porque é cancelada 25 minutos depois.

Quais poderiam ser as possíveis razões para isso?

Eu posso pensar em:

• servidor NTP remoto apenas fornece a hora errada
• problemas de rede (uma latência alta poderia introduzir tais desvios?)
• bissexto induzido por segundo (isso deve induzir uma falha, certo?)

Se a primeira alternativa foi o problema, como posso me proteger contra isso?

O NTPD é inteligente o suficiente para consultar vários servidores NTP (quando várias linhas server estão disponíveis em ntp.conf ) e detecta se respostas diferentes se desviam muito umas das outras?

    

Answer 1

Eu vi entradas de syslog como essa em uma máquina do Slackware há alguns anos. Acredito que comprei a máquina em questão em 2002, e praticamente a executei 24/7 por anos: era meu servidor SSH, SMTP e HTTP. As falhas do NTP ocorreram lentamente e aumentaram gradualmente em frequência.

Eu consertei a primeira vez mudando a bateria "CMOS RAM", que era uma das baterias CR2032 do tamanho de uma moeda (US quarter) na placa-mãe.

Após mais um ou dois anos de operação, a máquina simplesmente parou de manter o tempo com precisão e tive que reiniciar regularmente o ntpd . Pelo que entendi, ntpd mantém um "arquivo de inclinação" com base em dados anteriores de como o relógio local difere do (s) relógio (s) da rede. Meu palpite é que a placa-mãe em questão nunca teve um grande relógio, e o relógio finalmente ficou tão ruim que o "arquivo skew" simplesmente não conseguia acompanhar sua variação selvagem.