O que é dispersão NTP e como eu a controle?

Implementamos servidores Ubuntu 14.04 em redes isoladas, executando o ntpd 4.2.6p5, configurado para usar vários servidores NTP, conforme fornecido pelos clientes (sem acesso ao pool.ntp.org). Nossos dispositivos clientes terminais mudos executam uma versão antiga do BusyBox (1.00-rc2) e do ntpclient 2010 de Larry Doolittle.

Essa configuração funcionou muito bem por anos, mas recentemente alcançamos um obstáculo com um novo cliente. Eles nos forneceram cinco endereços de servidor NTP internos que parecem funcionar muito bem por conta própria, no que diz ntpdate-debianrespeito ao servidor Linux. No lado do BusyBox, no entanto, ntpclientreclama com "Dispersão muito alta". Na saída de depuração, ntpclientobtém "1217163.1" do servidor NTP, mas o valor máximo que ele suporta é absoluto (65536).

$ /usr/sbin/ntpclient -s -i 15 -h 10.17.162.250 -d
Configuration:
  -c probe_count 1
  -d (debug)     1
  -g goodness    0
  -h hostname    10.17.162.250
  -i interval    15
  -l live        0
  -p local_port  0
  -q min_delay   800.000000
  -s set_clock   1
  -x cross_check 1
Listening...
Sending ...
recvfrom
packet of length 48 received
Source: INET Port 123 host 10.17.162.250
LI=0  VN=3  Mode=4  Stratum=4  Poll=4  Precision=-20
Delay=60745.2  Dispersion=1346801.8  Refid=10.31.10.21
Reference 3668859928.942079
(sent)    3668859928.708371
Originate 3668859928.708371
Receive   3668859928.963271
Transmit  3668859928.963369
Our recv  3668859928.708371
Total elapsed:      0.00
Server stall:      93.09
Slop:             -93.09
Skew:          255443.94
Frequency:             0
 day   second     elapsed    stall     skew  dispersion  freq
42463 56728.708  rejected packet: abs(DISP)>65536

Estes são todos os dispositivos na mesma LAN, então, francamente, estou pasmo. Atordoado mesmo.

Aqui está a ntpq -pnsaída do servidor Ubuntu 14.04:

user@host:~$ ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 127.127.1.0     .LOCL.          10 l 1025   64    0    0.000    0.000   0.000
 10.17.162.249   10.17.6.10       5 u   23 1024   37    0.865  1381.07 697.260
 10.31.10.22     .LOCL.           1 u 1044 1024   17   29.586  -838.06 397.342
 10.17.6.10      10.31.10.21      4 u 1065 1024   17    0.366  105.245 402.999
*10.31.10.21     132.246.11.238   3 u    5 1024   37   29.418  794.292 616.796
 10.17.6.11      10.31.10.21      4 u 1038 1024   17    0.408  120.030 381.058

Minhas perguntas são:

1. O que é dispersão e o que pode alterar seu valor?
2. Quais comandos eu poderia executar para obter mais detalhes dos servidores NTP?
3. A falha pode estar no lado do servidor Ubuntu, com um erro ntp.conf? Não há nada de especial lá realmente.
4. Mudar para o chrony mudaria alguma coisa nesse caso?

Eu vejo alguma confusão acontecendo nas respostas aqui. Para iniciantes, ntpclientpelo menos no -smodo, não está atuando como um cliente NTP completo, está apenas enviando e recebendo um pacote ; portanto, não há "últimos 8 pacotes recebidos". Na verdade, não está estimando sua própria dispersão.

Em vez disso, o valor que está imprimindo é o valor chamado "dispersão raiz" (rootdisp) no pacote retornado pelo servidor, que é uma estimativa da quantidade total de erro / variação entre esse servidor e a hora correta. A maneira como isso é calculado é bem simples: todo servidor NTP obtém seu horário de um relógio externo (por exemplo, um receptor de rádio ou GPS) ou de outro servidor NTP. Se um servidor obtiver seu tempo com um relógio externo, sua dispersão raiz será o erro máximo estimado desse relógio. Se obtiver tempo de outro servidor NTP, sua dispersão raiz será a dispersão raiz desse servidor mais a dispersão adicionada pelo link de rede entre eles.

Um ponto de confusão aqui é que, enquanto ntpq e chrony exibem dispersão e dispersão de raiz em segundos, que é o que as pessoas estão acostumadas, o ntpclient exibe em microssegundos . Independentemente disso, um valor de 1217163 ainda é bastante alto. Um bom servidor NTP sabe o tempo dentro de alguns milissegundos; uma má dentro de algumas dezenas ou centenas de milissegundos. O seu está lhe dizendo que seu tempo só pode ser confiável em +/- 1,2 segundos.

Na verdade, é possível fazer com que o ntpclient sincronize com esse servidor de qualquer maneira, passando a opção -x 0ou -t(dependendo da versão do ntpclient), que desativa as verificações de integridade do NTP. Se você precisar apenas de tempo aproximadamente preciso (em alguns segundos), isso pode ser bom o suficiente. No entanto, o ntpclient está sendo bastante razoável ao se recusar a sincronizar com um servidor tão ruim. Sua ntpqsaída na máquina ubuntu está mostrando um jitter de centenas de milissegundos para todos os seus servidores, mesmo que eles tenham um atraso baixo, o que indica uma rede muito não confiável, uma conspiração de todos os servidores para fornecer tempo irregular ou uma solução básica. problema de cronometragem no próprio servidor.

Também me preocupa que o servidor 10.31.10.22 esteja anunciando um refid de LOCL(relógio local indisciplinado), mas que tenha um estrato de 1. Normalmente, o relógio local é falsificado para um estrato de 10, para que seja usado apenas como fonte de sincronização de último recurso para impedir que um rebanho se afaste. 10.31.10.22 está configurado incorretamente e está fornecendo problemas ao restante da rede, ou está sendo disciplinado com o tempo devido a algum programa fora do controle da NTP; nesse caso, a configuração incorreta é simplesmente a publicidade do LOCLrefid; ele deve ser substituído por, por exemplo, GPSou o que estiver fornecendo seu tempo.

Apenas uma resposta parcial para "O que é dispersão?":

Uma ida e volta típica do NTP:

client |        | server
    t1 |------->| t2
    t3 |<-------| t4

Isso gera dois valores, deslocamento (a diferença de horário entre cliente e servidor) e atraso (essencial no tempo de viagem da rede) com as seguintes fórmulas:

offset= ((t4 - t3) + (t1 - t2)) / 2
delay = (t4 - t1) - (t3 - t2)

O cliente seleciona o deslocamento atual dos últimos 8 pacotes recebidos, escolhendo aquele com o menor atraso.

Os mesmos 8 pacotes são usados ​​para calcular a dispersão , fazendo uma média ponderada da diferença dessas 8 compensações para a selecionada na última etapa, onde o atraso é usado como fator de ponderação, dando maior peso a atrasos menores. É uma medida para a "dispersão" dos valores e usada para calcular a qualidade de um servidor de horário, especialmente se você tiver vários para escolher.

Sua dispersão e inclinação são enormes, há um deslocamento muito grande do relógio local para esse ponto. Você deve comparar os deslocamentos com o local datee ajustar o relógio manualmente.

Execute o ntpd e mostre a ntpq -ppartir de um host usando todos os pares. Ele selecionará os melhores.

De acordo com esta documentação da Cisco , " dispersão , relatada em segundos, é a diferença máxima de horário do relógio que já foi observada entre o relógio local e o relógio do servidor". Com servidores ntp que não estão totalmente quebrados, uma alta dispersão nunca deve ocorrer. O único cenário possível é quando o cliente entra no NTP e, até o momento, apenas o relógio local está disponível. E mesmo assim, uma dispersão tão alta quanto você relata corresponde a relógios que são desativados por mais de duas semanas .

Deve ser suficiente garantir que o relógio local não esteja muito distante no início (até algumas horas ainda seriam aceitáveis), ajustando o relógio (e com data até!) No BIOS ou emitindo ntpdateuma vez antes de iniciar ntpdno cliente.