O que é dispersão de NTP e como posso controlá-lo?

Question

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

Essa configuração funcionou muito bem durante anos, mas recentemente atingimos um obstáculo com um novo cliente. Eles nos forneceram 5 endereços internos de servidores NTP que parecem funcionar bem sozinhos, na medida em que ntpdate-debian está preocupado com o servidor Linux. No entanto, no lado do BusyBox, ntpclient reclama com "Dispersão muito alta". Da saída de depuração, ntpclient obtém "1217163.1" do servidor NTP, mas o valor máximo suportado é 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, por isso, francamente, estou espantado. Espantado mesmo.

Aqui está a saída ntpq -pn 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 ntp.conf incorreto? Não há nada de especial nisso.
4. Mudar para chrony muda alguma coisa neste caso?

Answer 1

Eu vejo alguma confusão acontecendo nas respostas aqui. Para iniciantes, ntpclient , pelo menos no modo -s , não está agindo como um cliente NTP completo, está enviando e recebendo apenas um pacote , então 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á sendo impresso é o valor chamado "dispersão de 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 tempo de um relógio externo (por exemplo, um receptor de rádio ou GPS) ou de outro servidor NTP. Se um servidor obtém seu tempo de um relógio externo, sua dispersão de raiz é o erro máximo estimado desse clock. Se chegar a hora de outro servidor NTP, sua dispersão de raiz é a dispersão de raiz do servidor mais a dispersão adicionada pelo link de rede entre eles.

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

Na verdade, você pode obter o ntpclient para sincronizar com esse servidor transmitindo a opção -x 0 ou -t (dependendo da versão do ntpclient), o que desativa as verificações de integridade do NTP. Se você precisar apenas de um tempo aproximadamente preciso (em alguns segundos), isso pode ser bom o suficiente. No entanto, o ntpclient está sendo bastante razoável em se recusar a sincronizar com um servidor tão ruim. Sua saída ntpq na máquina ubuntu está mostrando um jitter de centenas de milissegundos para todos os seus servidores, mesmo que eles tenham pouco atraso, o que indica uma rede muito pouco confiável, uma conspiração de todos de os servidores para fornecer tempo errático, ou um problema básico 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 tenha um estrato de 1. Geralmente, o relógio local é falsificado para um estrato de 10, de modo que é usado apenas como uma fonte de sincronização de último recurso para evitar que um rebanho se distancie. 10.31.10.22 está configurado incorretamente e fornece tempo ruim para o resto da rede, ou está sendo disciplinado a tempo por algum programa fora do controle do NTP, caso em que a configuração incorreta é simplesmente que ele está anunciando o LOCL refid; deve ser substituído por ex. GPS ou o que estiver fornecendo seu tempo.

    

Answer 2

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

Uma viagem de ida e volta típica da NTP:

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

Isso gera dois valores, deslocamento (a diferença de tempo entre cliente e servidor) e o atraso (essencial, o 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 destes 8 deslocamentos para o selecionado na última etapa, onde o atraso é usado como o fator de ponderação , dando maior peso a atrasos menores. É uma medida para o "spread" dos valores e usado para calcular a qualidade de um servidor de horário, especialmente se você tiver vários para escolher.

    

Answer 3

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

Obtenha o ntpd em execução e mostre ntpq -p de um host usando todos os peers. Ele selecionará os melhores.

    

Answer 4

De acordo com o esta documentação do cisco ," dispersão , relatada em segundos, é a diferença máxima de tempo 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 viável é quando o seu cliente init ntp e até agora tem apenas o seu relógio local disponível. E mesmo assim, uma dispersão tão alta quanto você reporta corresponde a relógios que estão desligados por mais de duas semanas .

Deve ser suficiente garantir que o relógio local não esteja muito distante no início (algumas horas ainda seriam aceitáveis), seja ajustando o relógio (e a data mesmo!) no BIOS ou emitindo ntpdate uma vez antes de iniciar ntpd no cliente.