Aparentemente baixa qualidade da sincronização de tempo NTP usando um relógio GPS

Question

Eu tenho um servidor Linux que tem seu tempo sincronizado com um dispositivo NTP baseado em GPS localizado nas proximidades. Os tempos de ping do servidor para o dispositivo são cerca de 1 ms, com jitter muito baixo:

--- x.x.x.x ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 99001ms
rtt min/avg/max/mdev = 0.874/0.957/1.052/0.051 ms

No entanto, o cliente NTP estima que a precisão da sincronização de tempo seja em torno de 5-6ms, o que parece muito alto, considerando a configuração:

synchronised to NTP server (x.x.x.x) at stratum 2
   time correct to within 5 ms
   polling server every 16 s

ntpq -p fornece o seguinte:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*x.x.x.x         .PPS.            1 u   10   16  377    0.964   -0.019   0.036

Duas perguntas:

1. O que pode fazer com que o cliente NTP tenha uma confiança tão baixa na precisão da sincronização?
2. Existe alguma maneira de medir a precisão real da sincronização, digamos, para o milissegundo mais próximo?

Answer 1

O valor que ntpstat exibe após "tempo correto para dentro" é a dispersão raiz + atraso de raiz / 2. ntpq -p não mostra a "dispersão de raiz" em execução ntpq -c rl .

Não obstante, é claro que a principal fonte da falta de precisão é a dispersão, e não o atraso (que é de apenas 0,964).

A dispersão é o "erro nominal relativo à fonte de referência primária". Eu olhei brevemente através do NTPv4 RFC e é isso que tem a dizer:

The dispersion (epsilon) represents the maximum error inherent in the measurement. It increases at a rate equal to the maximum disciplined system clock frequency tolerance (PHI), typically 15 PPM. 1 PPM is equal to 10^(-6) seconds/second.

Para usar a terminologia rrdtool, a dispersão não é um indicador, mas sim um contador. Ver um valor grande pode não indicar que algo está errado.

Infelizmente, não consegui entender o algoritmo ntp bem o suficiente para ver como diminuir esse número. Eu notei que esse valor é redefinido ocasionalmente. Eu não sei porque.

    

Answer 2

A razão que eu perguntei sobre o hardware acima é porque muitos dispositivos GPS (stratum 0, a fonte 'root') se conectam ao computador que então atua como o servidor NTP através de um link serial.

As conexões seriais geralmente têm 1-5ms de jitter na linha devido a atrasos de sinalização / interrupções de espera. Assim, eu estou supondo que sua fonte NTP está lendo de uma fonte serial.

Existem alguns ajustes que você pode executar na conexão serial para reduzir o jitter. Primariamente, desabilitar o FIFO pode gerar resultados decentes.

link . link

    

Answer 3

O tempo correto dentro de 5 ms é ótimo !!! 5 ms é 5/1000 de segundo. Qualquer coisa abaixo de 100 ms é facilmente aceitável para qualquer coisa que não seja uma pequena quantidade de situações. Nesse caso, você não estaria usando GPS, mas um relógio atômico local e dois relógios de referência externos. Ficamos dentro de 10 ms com o pool ntp.