w32tm / resync não funciona instantaneamente

Question

Esta pergunta é principalmente para outras pessoas aprenderem e satisfazerem a minha própria curiosidade, se alguém souber porque faz o seguinte.

Tivemos um problema com o nosso DC não ter o tempo certo devido a ele ser virtualizado, que já foi corrigido. Mas alguns de nossos clientes e servidores precisavam do tempo atualizado. Então eu tentei executar os seguintes comandos como admin w32tm / query / source para ter certeza de que estava recebendo o tempo do nosso controlador de domínio e w32tm / resync para sincronizar a hora, ambos os comandos não tinham erros, mas o tempo não mudou.

Eu vejo algo semelhante à seguinte linha nos logs de eventos. O horário do sistema foi alterado para 2014-09-08T21: 31: 33.328000000Z de 2014-09-08T21: 31: 33.342455400Z.

Então, tento o comando mais algumas vezes sem alterações e faço uma pesquisa no Google um pouco, só para voltar e descobrir que o cliente está no momento certo, mas nada de novo nos logs de eventos.

Eu experimentei um segundo cliente com o mesmo resultado, mas não saí do cliente, mas dei uma olhada nos logs e, por pura sorte, olhei para o relógio e percebi que o tempo estava se aproximando do tempo real. . Estava diminuindo a velocidade na hora certa. De vez em quando o relógio aumentava em 2 segundos, ou um segundo mudava para o próximo dígito antes que um segundo inteiro passasse. Faria isso até o relógio ter atingido a hora certa.

Minha pergunta é por que isso acontece? por que não apenas mudar a hora para a hora correta instantaneamente, como faz o meu computador pessoal quando sincronizo a hora com um servidor NTP?

    

Answer 1

Aparentemente, isso ocorre por design:

If the local clock time of the client is less than three minutes ahead of the time on the server, W32Time will quarter or halve the clock frequency for long enough to bring the clocks into sync. If the client is less that 15 seconds ahead, it will halve the frequency; otherwise, it will quarter the frequency. The amount of time the clock spends running at an unusual frequency depends on the size of the offset that is being corrected

link

Não consigo encontrar uma referência que explique explicitamente por que foi projetada, mas imagino que o objetivo seja evitar saltos repentinos no caso de outros aplicativos estarem usando o relógio interno para operações de tempo. Portanto, se o deslocamento for baixo, o método 'convergência' é usado ajustando a taxa de relógio local. Se a diferença for de 3 minutos ou mais, o risco de falha na autenticação do Kerberos (> 5 minutos) é considerado mais sério do que os riscos envolvidos em 'saltar' o relógio local, portanto o relógio é apenas reiniciado em vez de convergir