Normalmente, quando uma máquina perde completamente a conexão, o ntpd perde algumas pesquisas e marca todas as fontes como falhadas. O que parece bastante lógico. Mas encontrei uma situação em que um servidor permanece marcado como fonte de horário atual enquanto seu alcance era 0.
O servidor é implantado na mesma sub-rede que uma máquina de destino, proporcionando atraso, deslocamento e jitter muito baixos. A situação foi modelada desligando fisicamente a conexão: apenas desconectando um cabo de uma máquina cliente. Tentei recriar isso, mas desde então a mesma máquina sempre perde o status de sincronização após 5 a 6 pesquisas malsucedidas.
A verdadeira questão é: o que determina exatamente o status da sincronização quando a conexão é perdida?
Responder1
Há uma explicação definitiva sobre o registro de alcance na RFC-1305:
O registro de alcançabilidade é deslocado uma posição para a esquerda, com zero substituindo o bit vago. Se todos os bits deste registrador forem zero, o procedimento clear é chamado para limpar o filtro de clock e selecionar novamente a fonte de sincronização, se necessário. Se a associação não foi configurada pelo procedimento de inicialização, a associação é desmobilizada.
No entanto, o RFC-1305 é obsoleto pelo RFC-5905, que não é tão distintivo:
Em seguida, o registrador de deslocamento p.reach de 8 bits no processo de pesquisa descrito na Seção 13 é usado para determinar se o servidor está acessível e se os dados estão atualizados. O registro é deslocado um bit para a esquerda quando um pacote é enviado e o bit mais à direita é definido como zero. À medida que pacotes válidos chegam, o bit mais à direita é definido como um. Se o registro contiver bits diferentes de zero, o servidor será considerado acessível; caso contrário, é inacessível.
Nenhum procedimento claro é mencionado na Seção 13. Mas ainda assim parece que um par inacessível deve perder seu status de sincronização em algum momento.
Consegui recriar o status sincronizado com a situação de alcance 0 para garantir que seja raro e nem um pouco permanente. Foi preciso desabilitar o "burst" na configuração dos servidores e quebrar a conexão logo após a sincronização.
remote refid st t when poll reach delay offset jitter
==============================================================================
91.198.10.4 194.190.168.1 2 u 20 64 177 51.137 -2.192 11.049
192.168.1.1 193.67.79.202 2 u 65 64 77 0.459 -1.818 0.922
remote refid st t when poll reach delay offset jitter
==============================================================================
*91.198.10.4 194.190.168.1 2 u 21 64 177 51.137 -2.192 11.049
+192.168.1.1 193.67.79.202 2 u - 64 177 0.449 -3.192 1.828
O alcance foi 177, que é 01111111 em binário. Portanto, foram necessárias 7 pesquisas para estabelecer a sincronização.
A sincronização então foi perdida nesta posição:
remote refid st t when poll reach delay offset jitter
==============================================================================
+91.198.10.4 194.190.168.1 2 u 574 64 0 63.846 -9.652 0.756
*192.168.1.1 193.67.79.202 2 u 553 64 0 0.449 -3.192 0.505
remote refid st t when poll reach delay offset jitter
==============================================================================
91.198.10.4 194.190.168.1 2 u 575 64 0 69.871 -10.409 0.002
192.168.1.1 193.67.79.202 2 u 554 64 0 0.449 -3.192 0.505
Quando os números são um pouco estranhos como 64 * 9 = 576 e não 575, mas eu acho que a representação pode ser imprecisa de 1 segundo. Considerando isso, foram necessárias 9 pesquisas sem sucesso para quebrar o status de sincronização.
Assim, considerando a teoria e a prática, parece que o estado em que a fonte com alcance 0 pode ser considerada fonte de tempo atual é possível, mas também raro e temporário.