Inexactidão do estrato do NTP [fechada]

Question

Estamos nos preparando para ter um argumento sobre o estrato NTP como um indicador de precisão de tempo. A declaração que começou tudo foi:

Stratum 5 can be four minutes off.

Meu entendimento é que o NTP tenta fazer o máximo possível, independentemente de quantos hops (stratum) você está longe de um clock autoritativo. Eu entendo que quanto maior o número do estrato significa que você tem mais chance de um servidor de tempo ter ido mal ou uma rede escamosa causando cálculos incorretos. Eu entendo mais do que apenas estrato (jitter, latência, etc.) deve ser examinado para determinar o quão preciso é um relógio. Eu também entendo que deve haver 3 ou 4 (ou mais?) Servidores de tempo upstream para redundância e confiabilidade estatística.

Internamente, vários sistemas de produção são o stratum 5. Não consigo acessar meu sistema de teste do stratum 5 para um stratum 2 para obter um offset.

ntpdate -q 1.debian.pool.ntp.org
server 208.53.158.34, stratum 0, offset 0.000000, delay 0.00000
 6 Jan 15:47:46 ntpdate[]: no server suitable for synchronization found

Mas entrar em contato com alguns dos meus servidores internos do estrato 3, essa diferença é de cerca de -0,007. (Ou ainda menos!)

Estou à procura de argumentos que posso dar aos gestores não técnicos para aliviar os seus medos. Agora estou inclinado para algo assim.

Stratum is only a measurement of the number of hops from an authoritative clock. Our internal NTP servers receive time from stratum 2 servers. This is pretty standard across the Internet. (Else the stratum 1 servers would become overloaded. Overloaded time servers report incorrect time.) The difference between our internal stratum 3 servers and the stratum 5 production systems is roughly 7 thousands of a second. Strata 3, 4, and 5 time servers are all owned by us and communicate over our network. Unless our internal stratum 3 time servers (used as the source of time for the entire company) are wildly inaccurate, we shouldn't worry about stratum as an indicator of system time accuracy.

Eu percebo que preciso fazer com que a gerência diga qual é a imprecisão aceitável. (Não estamos envolvidos em decisões de vida e morte, não fornecemos serviços de tempo aos clientes, nem negociamos ações onde os segundos de imprecisão nos expõem a grandes obrigações monetárias. Eu entendo por meio de conversas que 4 minutos importam para alguns departamentos de negócios. Heck, quatro minutos provavelmente deixariam o NFS enlouquecer!)

Alguém pode apontar onde meu raciocínio e processo estão errados? Existem melhores argumentos? Existem sites / links descrevendo (in) a precisão do tempo conforme o número de estratos aumenta que eu possa usar como pesquisa?

    

Answer 1

Como você afirmou, o stratum mede apenas o número de saltos de um servidor que afirma ser confiável. Se você estiver usando servidores confiáveis com boa conectividade, é improvável que você esteja longe do horário padrão. Suas conclusões estão corretas. A precisão do seu servidor de horas depende dos seus servidores com menor estrato. Eu iria com a sua declaração, resume bem as coisas.

Soma o atraso mais o deslocamento de todos os estratos para obter uma variância de pior caso. Isso pressuporia tempos de transferência de rede maximamente assimétricos. Isso deve ficar bem abaixo de um segundo no stratum 5. Internamente, você só precisa considerar o offset de seus servidores do stratum 3 (que deve ser observado). Isso parece ser extremamente baixo em sua rede.

Seus servidores de nível 3 devem poder relatar os dados para seus servidores de nível 2. Eu me conecto a servidores de tempo em um túnel IPv6 e tenho atrasos de 35 a 70 ms. As compensações estão abaixo de 4 ms. Os tempos de pesquisa são 1024 segundos (cerca de 17 minutos).

Dentro de uma rede corporativa, espero que os servidores que usam o NTP sejam sincronizados com alguns centésimos de segundo. Parece que sua organização conseguiu isso. Eu experimentei offsets de minutos, mas aqueles ocorreram em servidores que não estavam sincronizando. Há vários programas que podem monitorar servidores NTP e relatar se há problemas.

Sinaliza que há um problema para investigar:

• Um deslocamento alto (em alguns milissegundos)
• Um tempo de pesquisa baixo em um servidor. (Isso é normal logo após ser iniciado, mas deve subir rapidamente para 1024).
• Um jitter alto (embora possa ser um pouco mais alto que o offset).
• Um atraso alto (depende da distância, mas normalmente de alguns centésimos de segundo.
• Valores de acessibilidade diferentes de 377 em um servidor que está em execução há mais de 10 minutos.

Eu derrubo servidores que mostram mais de um ou dois desses sinalizadores.

Dentro de uma rede, todos esses valores devem ser muito baixos, e a contagem de estratos não deve ser um fator significativo. Desde que o nível fique abaixo do estrato atribuído ao estrato do relógio local, não deve permitir diferenças de tempo significativas.

Eu pesquisei sistemas com servidores de estrato 1 que relatavam vezes os dias fora do horário correto. Provavelmente, eles estavam usando o relógio local sem um fator de correção. (Eu uso 10, mas considero qualquer nível acima de 8 como suspeito.) Felizmente, você escolhe seus servidores de tempo.