¿Qué es la dispersión NTP y cómo la controlo?

20

Implementamos servidores Ubuntu 14.04 en redes aisladas, ejecutando ntpd 4.2.6p5, configurado para usar múltiples servidores NTP según lo provisto por los clientes (sin acceso a pool.ntp.org). Nuestros tontos dispositivos cliente de terminal ejecutan una versión anterior de BusyBox (1.00-rc2) y ntpclient 2010 de Larry Doolittle.

Esta configuración ha funcionado muy bien durante años, pero recientemente hemos llegado a un obstáculo con un nuevo cliente. Nos proporcionaron 5 direcciones de servidor NTP internas que parecen funcionar muy bien por sí mismas, en lo que ntpdate-debianrespecta al servidor Linux. Sin embargo, en el lado de BusyBox, se ntpclientqueja con "Dispersión demasiado alta". De la salida de depuración, ntpclientobtiene "1217163.1" del servidor NTP pero el valor máximo que admite es 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

Todos estos dispositivos están en la misma LAN, así que, francamente, estoy asombrado. Horrorizado incluso.

Aquí está la ntpq -pnsalida del 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

Mis preguntas son:

  1. ¿Qué es la dispersión y qué puede alterar su valor?
  2. ¿Qué comandos podría ejecutar para obtener más detalles de los servidores NTP?
  3. ¿Podría la falla recaer en el lado del servidor Ubuntu, con un incorrecto ntp.conf? No hay nada especial allí realmente.
  4. ¿Cambiar a Chrony cambiaría algo en este caso?
Jeff
fuente
Solo suponiendo: ¿son buenos los relojes de los cinco servidores NTP proporcionados? ¿Puedes eliminar los peores de tus configuraciones?
Criggie
1
Sus compensaciones y nerviosismo son demasiado altos. Obtenga al menos una fuente adecuada.
Restablece a Monica - M. Schröder el

Respuestas:

21

Veo cierta confusión en las respuestas aquí. Para empezar, ntpcliental menos en -smodo, no está actuando como un cliente NTP completo, solo está enviando y recibiendo un paquete , por lo que no hay "últimos 8 paquetes recibidos". En realidad, no está estimando su propia dispersión en absoluto.

En cambio, el valor que está imprimiendo es el valor llamado "dispersión raíz" (rootdisp) en el paquete devuelto por el servidor, que es una estimación de la cantidad total de error / variación entre ese servidor y el tiempo correcto. La forma en que se calcula esto es bastante simple: cada servidor NTP obtiene su tiempo de un reloj externo (por ejemplo, un receptor de radio o GPS) o de otro servidor NTP. Si un servidor obtiene su tiempo de un reloj externo, su dispersión raíz es el error máximo estimado de ese reloj. Si obtiene su tiempo de otro servidor NTP, su dispersión raíz es la dispersión raíz de ese servidor más la dispersión agregada por el enlace de red entre ellos.

Un punto de confusión aquí es que mientras ntpq y chrony muestran la dispersión y la dispersión de la raíz en segundos, que es a lo que la gente está acostumbrada, ntpclient lo muestra en microsegundos . En cualquier caso, un valor de 1217163 sigue siendo bastante alto. Un buen servidor NTP conoce el tiempo en unos pocos milisegundos; uno malo en unas pocas decenas o cientos de milisegundos. El tuyo te dice que solo se puede confiar en su tiempo en +/- 1.2 segundos.

De todos modos, puede hacer que ntpclient se sincronice con este servidor pasando la opción -x 0o -t(dependiendo de la versión de ntpclient), que deshabilita las comprobaciones de sanidad NTP. Si solo necesita un tiempo más o menos preciso (en unos pocos segundos), puede ser suficiente. Sin embargo, ntpclient está siendo bastante razonable al negarse a sincronizarse con un servidor tan malo. Su ntpqsalida en la máquina ubuntu muestra una inquietud de cientos de milisegundos para todos sus servidores, a pesar de que tienen un retraso bajo, lo que indica una red muy poco confiable, una conspiración de todos los servidores para proporcionar un tiempo errático o un error básico. problema de cronometraje en el propio servidor.

También me preocupa que el servidor 10.31.10.22 esté anunciando un rechazo de LOCL(reloj local indisciplinado) pero tiene un estrato de 1. Por lo general, el reloj local está falsificado a un estrato de 10 para que solo se use como fuente de sincronización de último recurso para evitar que una manada se separe. O 10.31.10.22 está mal configurado y proporciona un mal momento para el resto de la red, o está siendo disciplinado a buen tiempo por algún programa fuera del control de NTP, en cuyo caso la mala configuración es simplemente que está anunciando la LOCLdevolución; debe ser anulado, por ejemplo, GPSo lo que sea que esté proporcionando su tiempo

hobbs
fuente
Fantástica respuesta. Lo intentaré -x 0o -tinformaré de nuevo. Al respecto 10.31.10.22, podría sacarlo de la lista de servidores. Gran captura Realmente no tengo ninguna información sobre estos servidores, ¿hay algún otro comando de depuración para obtener detalles de un servidor NTP o es más o menos ntpq -p?
Jeff
Como dijiste, el -tconmutador confía en el servidor NTP interno a pesar de la alta dispersión. Todavía no podemos explicar por qué tiene picos aleatorios como ese, pero tal vez sea para otra publicación. Gracias.
Jeff
@Jeff contento de ayudar :)
hobbs
12

Solo una respuesta parcial para "¿Qué es la dispersión?":

Un típico viaje redondo de NTP:

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

Esto produce dos valores, compensación (la diferencia horaria entre el cliente y el servidor) y el retraso (esencial el tiempo de viaje de la red) con las siguientes fórmulas:

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

El cliente selecciona el desplazamiento actual de los últimos 8 paquetes recibidos, eligiendo el que tenga el menor retraso.

Los mismos 8 paquetes se usan para calcular la dispersión haciendo un promedio ponderado de la diferencia de estos 8 desplazamientos con el seleccionado en el último paso, donde el retraso se usa como factor de ponderación, dando mayor peso a retrasos más pequeños. Es una medida para la "dispersión" de los valores y se utiliza para calcular la calidad de un servidor de hora, especialmente si tiene múltiples para elegir.

Sven
fuente
¿Seguro de las fórmulas? Después de todo, solo t4-t2 y t3-t1 son conocidas por las partes involucradas
Hagen von Eitzen
@HagenvonEitzen El tiempo se puede incluir en el paquete
Thomas
@Sven También creo que hay un problema con las fórmulas; vea la página 28 aquí y también este Libro Blanco , ambos por Mills. Por cierto, tiene sus t establecidas, debería ser offset = 1/2 * [(T2-T1) + (T4-T3)]y `delay = (T3-T1) - (T4-T2) '
Ian Riley
Sven, ¿tienes t3/t4el lugar correcto en tu típico viaje de ida y vuelta? El flujo de tráfico y el cálculo del retraso parecen indicar que deberían ser al revés: t4 -t1debería ser el RTT total, t3-t2debería ser el tiempo invertido dentro del servidor.
7

Su dispersión y sesgo son enormes, hay un desplazamiento muy grande del reloj local a ese par. Debe comparar los desplazamientos con el local datey configurar el reloj manualmente.

Obtenga ntpd en ejecución y muestre ntpq -pdesde un host utilizando todos los pares. Seleccionará los mejores.

John Mahowald
fuente
ntpq -pnSalida agregada a mi pregunta. Gracias por examinar esto.
Jeff
44
Compensación y nerviosismo en los cientos? Eso no es muy bueno. Usted mencionó que no hay acceso a fuentes de Internet como pool.ntp.org, pero que funcionan mucho mejor. Considere agregar un reloj de referencia como GPS, una fuente de radio, una entrada PPS o similar. O elija un anfitrión con un reloj local que no esté por todas partes.
John Mahowald
5

De acuerdo con esta documentación de Cisco , "la dispersión , informada en segundos, es la diferencia máxima de tiempo de reloj que se observó entre el reloj local y el reloj del servidor". Con los servidores ntp que no están totalmente rotos, nunca debería producirse una alta dispersión. El único escenario factible es cuando su cliente inicia ntp y hasta ahora solo tiene disponible su reloj local. E incluso entonces, una dispersión tan alta como se informa corresponde a los relojes que están apagados por más de dos semanas .

Debería ser suficiente para garantizar que el reloj local no esté demasiado alejado al principio (incluso un par de horas aún sería aceptable), ya sea ajustando el reloj (¡y hasta la fecha!) En el BIOS o emitiéndolo ntpdateuna vez antes de comenzar ntpden el cliente

Hagen von Eitzen
fuente
1
ntpclient informa valores en microsegundos, por lo que la dispersión indicada es en realidad ~ 1.2 segundos, no semanas :) Además, la interpretación en ese documento de Cisco no se aplica a este valor.
hobbs