Existe material de pesquisa sobre a precisão do NTP disponível?

Tanto quanto eu sei, a precisão da sincronização NTP depende muito da rede. Eu já vi alguns números de 50 microssegundos a "menos de um segundo" na Internet. Bem, isso é uma enorme diferença.

Acredito que a dependência da precisão é uma ótima pergunta para estudar, mas até agora não consegui encontrar nenhum material, que afirma claramente que, digamos, alguma configuração específica concede essa precisão específica.

É dito em http://www.ntp.org/ntpfaq/NTP-s-algo.htm :

É necessária uma diferença de tempo menor que 128 ms entre o servidor e o cliente para manter a sincronização NTP. A precisão típica na Internet varia de cerca de 5ms a 100ms, possivelmente variando com os atrasos da rede. Uma pesquisa recente [2] sugere que 90% dos servidores NTP têm atrasos na rede abaixo de 100ms e cerca de 99% são sincronizados em um segundo ao ponto de sincronização.

Com a sincronização do PPS, é possível obter uma precisão de 50µs e uma estabilidade abaixo de 0,1 PPM em um PC Pentium (executando o Linux, por exemplo).

Isso é alguma coisa, mas talvez haja alguma análise mais aprofundada sobre o assunto?

Ninguém pode garantir quão bem o NTP funcionará na sua rede, porque ninguém sabe o quão bem sua rede está conectada à Internet e aos servidores de relógio nela. No entanto, de acordo com a página do algoritmo de disciplina do relógio em ntp.org

Se deixado em execução contínua, um cliente NTP em uma LAN rápida em um ambiente doméstico ou de escritório pode manter a sincronização nominalmente dentro de um milissegundo. Quando as variações de temperatura ambiente são inferiores a um grau Celsius, a frequência do oscilador de relógio é disciplinada em uma parte por milhão (PPM), mesmo quando o deslocamento da frequência nativa do oscilador de relógio é de 100 PPM ou mais.

Observe que a latência grande, mas estável, entre sua LAN e os servidores de clock da Internet não tem um efeito tão ruim na precisão quanto a latência altamente variável.

Você não diz onde obteve as estimativas acima ('50 microssegundos para ... "abaixo de um segundo" '), então não posso comentar sobre elas, mas, na minha experiência, 50us é improvável, a menos que você tenha uma conexão direta. fonte de relógio e 1s é improvável, a menos que você tenha um pedaço de fio molhado conectando-o à Internet e esteja usando servidores upstream na Antártica.

Editar : o texto que você cita agora em sua pergunta fornece um apontador para um artigo que, em 1999, estabeleceu de fato que 99% dos servidores ntp são sincronizados em um segundo. Felizmente, há trabalhos mais recentes; no presente trabalho alguns autores da Universidade Federal do Paraná, Brasil, repetiu a experiência em 2005, e encontrou (se eu entendi sua figura 1 corretamente.) que norte de 99% - mais parecido com 99,5% - de servidores têm agora offsets menos de 100ms e 90% têm compensações inferiores a 10ms. Isso se encaixa muito bem nas minhas experiências (veja acima).

Editar 2 : uma última ruga: todos esses estudos não investigam a precisão do relógio local, mas a que distância ele difere do relógio de referência upstream. Estes não são evidentemente a mesma coisa. Mas o primeiro é incognoscível; para saber quão errado é o seu relógio, você precisa saber exatamente a que horas são, e se você soubesse disso, por que teria acertado o relógio em primeiro lugar? Lembre-se de que o que esses estudos estão medindo não é a diferença entre o relógio local e o tempo absoluto, mas entre o relógio local e o relógio de referência.

Que problema você está tentando resolver?

A solução que encontrei para ambientes que exigem mais precisão que o NTP é o PTP (Precision Time Protocol) . Eu já tive isso em aplicativos de computação científica e de computação financeira. Existem vantagens , no entanto.

Veja também: sincronização de horário ptp no centos6 / rhel

Algumas outras coisas que vale a pena mencionar:

• Você terá sorte em obter <100ms de jitter de relógio em uma máquina virtual; portanto, tudo a seguir é para um host físico
• O jitter de sub 100ms é quase incomensurável para quase todas as tarefas, e facilmente alcançável pela Internet
• O jitter de sub-30ms pode ser necessário para alguns ambientes de atendimento geral (eu precisava dele para correlação de log em um trabalho anterior) e é facilmente alcançado usando servidores NTP no mesmo continente em que a conexão não é por meio de links "consumidores" (por exemplo, não por satélite , ADSL, DOCSIS, GPON, UMTS / LTE / HSPA / etc)
• Para uma precisão absoluta abaixo disso, você deve instalar servidores NTP de hardware de um fornecedor de qualidade (por exemplo, Symmetricom)
• O acordo local de sub 10 ms (geralmente sub 1 ms) pode ser alcançado facilmente, basta ter um trio (você pode fazer com menos, mas há razões para usar três ou cinco) no mesmo datacenter o suficiente para praticamente todos os aplicativos que não são da Science

Interesse da minha parte: sou agente da Meinberg :-)

Sim NTP pode alcançar uma precisão de ponta a ponta até aprox. 50 nós (ou seja, microssegundos) de jitter, se você sincronizar um "cliente" linux no bare metal executando o Chrony ou o ntpd, em um servidor NTP baseado no Linux, disciplinado por GPS, relógio atômico local ou alguma fonte desse tipo.

Na máquina que possui um GPS local (com uma interconexão PPS), você provavelmente verá 0-2 microssegundos de deslocamento, entre a instância ntpd em execução no sistema operacional e a entrada do driver de refclock do PPS.

Esses 50 nós residuais "de ponta a ponta em uma LAN" são o resultado de vários estágios de buffer, latência variável de IRQ, outro tráfego que interfere na LAN e nos barramentos de computador envolvidos e outros enfeites. 50 nós significa uma LAN com muito pouco tráfego. Mesmo apenas um switch pode adicionar alguns microssegundos de instabilidade - e os switches de ponta com recursos complexos adicionam mais latência e instabilidade. Em outras palavras, pode ser bem difícil atingir esses 50 microssegundos nas condições do mundo real em alguma LAN prática.

Da mesma forma, esses cca <2us do deslocamento do PPS resultam apenas da incerteza de latência do IRQ e da instabilidade geral da latência do barramento no hardware do PC bem comportado.

Observe que o NTP e suas implementações ntpd e Chrony certamente medem o tempo de ida e volta da transação NTP e subtraem (adicione, na verdade) metade dessa ida e volta, como uma medida para filtrar a latência sistemática do transporte (só ida). Eles também executam rejeição externa, consenso de quorum, eleição de syspeer e qualquer demônio do NTP filtra as respostas recebidas em suas consultas upstream. Assim como outros disseram, os milissegundos que você vê no Ping e no Traceroute não compensam diretamente o relógio local. O que importa é a variabilidade do ida e volta da transação, ou seja, outro tráfego no caminho para o servidor NTP upstream. Ntpq -p é seu amigo.

Um receptor GPS básico para uso de tempo, com um TCXO, pode ter talvez 100-200 ns de instabilidade residual + desvio em sua saída PPS. Muito bom para o NTP, desde que o GPS permaneça bloqueado. (O desempenho da retenção não é muito bom com os TCXOs.) Um GPS de temporização de qualidade com um OCXO pode estar dentro de 100 ns, talvez mais como 10-30 ns de erro residual (compensado pelo UTC global).

Observe que os satélites reais sobrevoando e irradiando para você através de uma atmosfera podem ser um jogo um pouco mais difícil para o receptor do que fazer comparações em laboratório com um gerador de GPS.

PTP é um martelo. Você precisa de suporte de HW no grandmaster, nos escravos e em qualquer switch - mas se conseguir tudo isso, são possíveis compensações residuais até o dígito duplo baixo de nanossegundos. Eu pessoalmente vi isso no ptp4l executando com uma placa de rede i210 com suporte a HW (registro de data e hora com uma resolução de nanossegundos).

O chip i210 é uma maravilha. Possui 4 pinos de uso geral que podem ser usados ​​para entrada ou saída de um sinal PPS. A placa NIC de addon Intel de referência com o i210 (e suas versões OEM de vários grandes fornecedores) vem equipada com um cabeçalho de pinos que fornece acesso a pelo menos 2 desses pinos GPIO (SDP's que são chamados pela Intel). Além de implementar uma porta PTP grandmaster, a entrada PPS pode ser aproveitada para um registro de data e hora preciso na captura de pacotes. Você precisa de uma fonte precisa de PPS e de um software personalizado para executar um loop servo, ajustando o PHC do i210 com o ext.PPS. No meu equipamento de teste, isso resultou em um dígito ns (por 1 s de iteração) do deslocamento residual. Essa é a precisão que você obtém nos carimbos de data e hora da captura, se você executar um tcpdump ou wireshark recente em um kernel Linux moderno (todo o software precisa de suporte para resolução em nível de nanossegundo). Melhor ainda: fui até o fim e construí um sintetizador PLL simples para produzir 25 MHz para os relógios NIC, bloqueados para uma referência precisa de 10MHz a montante. Depois disso, o deslocamento residual no loop servo do meu equipamento de captura de pacotes caiu para um 0 limpo (uma prova de que minha referência de 10 MHz é sincronizada com o PPS da mesma caixa GPS).

Observe que os grandes mestres de PTP podem ser especificados para fornecer carimbos de data e hora com uma granularidade real por 8 ns (em um tipo de dados com resolução de 1 ns). Isso faz sentido - a Ethernet gigabit tende a usar um relógio de 125 MHz, usado como relógio de byte nas partes internas do MAC, este relógio provavelmente também é usado no GMII e também é o relógio de símbolo no 1000Base-TX metálico (quatro pares em paralelo, 2 bits por símbolo por par). Portanto, a menos que você esteja usando 1000Base-FX (fibra ótica) com SERDES e uma implementação extremista da unidade de registro de data e hora HW no PHY que funciona em bits SERDES individuais, esses 8 ns são tudo o que você realmente pode esperar na Ethernet de gigabit. Algumas planilhas de dados de chips (com suporte a PTP) chegam a afirmar que o caminho de dados MII não está livre de buffer e que algumas variações podem surgir a partir daí.

Os pacotes PTP, na verdade, contêm registros de data e hora armazenados em um tipo de dados que permite uma resolução profunda de sub-nanossegundos. Mas o "campo fracionário abaixo de nanossegundo" hoje em dia normalmente não é utilizado. AFAIR apenas o projeto White Rabbit (relacionado ao CERN, o centro de pesquisa suíço) implementou a precisão sub-ns até agora.

O PTP também está disponível em software puro, sem aceleração de HW. Nesse caso, para um GM baseado em SW e um cliente baseado em SW, espere obter uma instabilidade residual semelhante à do NTP - ou seja, cerca de 50 nós em uma LAN dedicada, mas desconhecida por PTP. Lembro-me de ter obtido precisão de sub microssegundos de um grande mestre de HW em uma interconexão direta (sem alternância entre eles) e de um cliente apenas de SW (em uma NIC de PC desconhecida do PTP). Comparado ao NTP, o servo do PTP converge muito mais rapidamente.

Enquanto fazia algumas "tarefas de casa", ocorreu-me recentemente que o transporte de PPS ou sinais de tempo "discretos" semelhantes por rotas de fibra óptica de área ampla pode ser suscetível ao tempo de propagação dependente da temperatura "vagar". E embora eu não tenha como testar isso experimentalmente, algumas fontes nas inter-redes citam números entre 40 e 76 picossegundos por km e Kelvin. Observe que, embora esse tipo de "desvio térmico" seja impossível de mitigar "em banda" na transmissão PPS simplex, o PTP pós-compensaria isso inerentemente, com base em suas medições de atraso de caminho padrão (que depende da transmissão full duplex).

É o suficiente para uma visão geral de como são as "precisões", em diferentes tecnologias / interfaces de temporização. Qual nível de precisão é bom o suficiente para você, que depende da sua aplicação, das suas necessidades reais.