é normal que um clock do sistema seja inclinado por 500ms após a reinicialização?

Question

Se eu iniciar $ ntpq -p prontamente, depois de uma reinicialização, posso ver que o clock do sistema está desativado em até 600ms.

Demora um tempo antes que converge para o tempo NTP correto, por isso, levemente irritante em nosso caso de uso. (Monitores Ceph, que são sensíveis ao tempo). A seguinte reinicialização mostraria novamente um relógio distorcido.

Isso é esperado após uma reinicialização, ou seja, o RTC de um PC é impreciso?

Coisas que fiz para investigar:

1. Já o vi em vários servidores, embora muito semelhantes (HP dl360 gen9). Mas também um antigo desktop de etiqueta branca de 2009.
2. Salva um horário NTP convergido no RTC e depois copiou do RTC para o relógio do sistema. Eu só posso ver na ordem de 10ms de inclinação. Talvez ingênuo, mas isso basicamente imita uma reinicialização no que diz respeito ao tempo do sistema.
3. Salva explicitamente no RTC antes de reinicializar; ainda ocorre
4. Usado kexec-reboot; ainda ocorre.
5. Até agora testado apenas com o Ubuntu 16.04.

Answer 1

É bem possível que o RTC armazene segundos e, assim, (a menos que o kernel saiba quando muda de um segundo para o próximo), ele estará inerentemente desligado por até ½ segundo, ou seja, 500 ms. O mesmo se aplica ao economizar tempo no RTC; a menos que o kernel possa controlar quando o tick 1s acontece, o salvamento é desativado em até 500 ms.

A solução óbvia é fazer com que o NTP corrija mais rápido: se você iniciar o ntpd com -g (ou até mais com força, -G ), será permitido (ou forçado) acelerar o tempo de inicialização. Em conjunto com iburst em suas linhas server / pool , você deve obter um relógio preciso em dez segundos ou mais.

Você pode usar, por exemplo, ntp-wait para não iniciar suas cargas de trabalho sensíveis ao tempo até que o NTP esteja pronto.