Ntpd excessivamente impreciso

Question

Eu tenho o ntpd configurado (Meinberg ntp-4.2.6p5@london versão para Windows em um cliente Windows 7) com um monte de servidores próximos selecionados para tempos de ping baixo (geralmente 10-20ms ping). No entanto, parece que o meu relógio só é preciso dentro de 100ms ou menos, e não melhora com o tempo. Eu teria pensado que pode ter muito mais precisão do que o tempo de ping, isso é decepcionante. Como fazer isso funcionar melhor?

ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+pool-test.ntp.o 216.218.254.202  2 u  259 1024   17   12.920  -106.39 111.972
+palpatine.steve 208.201.242.2    3 u  239 1024   17   16.959  -102.84 112.056
+grom.polpo.org  127.67.113.92    2 u  259 1024   17   17.362  -184.43  74.468
+paladin.latt.ne 204.123.2.72     2 u  378 1024    3   24.211  -106.97  61.825
+public-ntp1.iso 204.13.164.164   3 u  259 1024   17   33.080  -100.17  65.970
+nist1.symmetric .ACTS.           1 u  214 1024   17   17.548  -108.30 111.951
*nist1-sj.ustimi .ACTS.           1 u  245 1024   17   21.826  -111.02  63.313

Como o jitter e o offset podem ser muito maiores que o atraso? Estar fora por 100ms quando o tempo de ping é 12ms parece ridículo, estou lendo isso errado?

Na verdade, eu não tenho certeza se o ntp está fazendo alguma coisa para mudar meu relógio - parece ter um tempo, mas não necessariamente definir qualquer coisa. Como posso verificar?

Mais alguns bits de informação:

ntpdc> sysinfo
system peer:          nist1-sj.ustiming.org
system peer mode:     client
leap indicator:       00
stratum:              2
precision:            -11
root distance:        0.02182 s
root dispersion:      0.15431 s
reference ID:         [216.171.124.36]
reference time:       d4dae2b5.3c32ce54  Fri, Mar  1 2013  0:17:57.235
system flags:         auth monitor ntp kernel stats
jitter:               0.045776 s
stability:            0.000 ppm
broadcastdelay:       0.000000 s
authdelay:            0.000000 s

more "c:\Program Files (x86)\NTP\etc\ntp.drift"
192.049

more "c:\Program Files (x86)\NTP\etc\ntp.conf"
driftfile "C:\Program Files (x86)\NTP\etc\ntp.drift"
server nist1.symmetricom.com iburst
server nist1-sj.ustiming.org iburst
server 149.20.68.17 iburst
server 173.230.144.109 iburst
server 65.19.178.219 iburst
server 204.2.134.162 iburst
server 173.230.144.109 iburst
server 207.115.64.229 iburst

O ideal é que eu queira um tempo que não esteja a mais de 50ms da mediana dos servidores configurados, se algum dia ele for mais longe, eu quero que ele dê certo. Existe alguma opção de configuração que eu possa definir que faria o ntp fazer isso?

    

Answer 1

O jitter (também conhecido como dispersão no NTP mais antigo) pode e irá variar muito ao longo do tempo. Especialmente se você tiver uma configuração em que a conexão entre você e o servidor NTP esteja congestionada. Você precisará executar "ntpq -p" com freqüência (sobre cada "poll" segundos) para monitorar o jitter ou ativar o arquivo de desempenho ("statsdir" e "statistics" linhas no arquivo ntp.conf).

link link

Ideally I want a time that is no more than 50ms away from the median of the configured servers, if it ever gets further away I want it to step. Is there any config option that I can set that would make ntp do that?

O NTP não funciona dessa maneira. Escolhe um servidor da sua lista, marca com '*' (asterisco, fonte de tempo de referência de a.k.a) na primeira coluna da saída 'ntpq -p' e tenta segui-lo. No caso em que a fonte de tempo de referência se tornou inacessível, ela voltará a seguir um dos servidores '+' (candidatos qualificados).

Sugiro:

1. Não usando iburst em todos os servidores
2. Escolhendo seu melhor servidor, usando iburst e marcando-o com preferência, ou seja, "server tick.example.com iburst prefer".
3. Escolha apenas 3 servidores próximos.
4. Mais uso dos nomes DNS do pool regional (como [0-3] .us.poo.ntp.org) para o restante.
5. Grave pelo menos 4 servidores de referência totais, mas não mais que 9.
6. Nunca configure uma linha "servidor 127.127.1.0" (também conhecida como relógio local) ou "fudge".

Por padrão, a opção "slew" versus "step" é de 128 ms. Se o deslocamento de tempo for > 128ms, ele vai pisar em vez de girar. Veja o parâmetro "-x" do "ntpd" (que nunca deve ser usado, a menos que você tenha um software que enlouqueça se o relógio for pisado).

Além de "ntpq -p", você também pode querer olhar para "ntpdc -c loopinfo".

    

Answer 2

O NTP foi projetado para obter um tempo preciso em 1s, em praticamente qualquer rede. Então, a esse respeito, 100ms está funcionando corretamente. No uso atual, o NTP geralmente mantém o tempo dentro de 20ms em quase qualquer hardware e 5-10ms em hardware com um RTC estável.

Se o seu servidor estiver continuamente desligado por números consistentes (em comparação com seus pares), provavelmente haverá muito jitter em seu RTC. NTP poderia compensar isso por bater seus pares para obter constantemente o tempo "certo". No entanto, isso não é recomendado e não é muito cortês com quem você está olhando.

O NTP não "ajusta" o relógio (por padrão). Ele "balança" o relógio, fazendo com que ele corra um pouco mais rápido ou mais devagar até que o relógio atinja o tempo desejado. A taxa de variação é então reajustada para compensar o "desvio" (a quantidade que o NTP calculou para o RTC ser rápido ou lento em comparação com os pares).

Além disso, concordo com todas as recomendações do Respondente da tgharold.