Solución 1:
Veo cierta confusión en las respuestas aquí. Para empezar, ntpclient , al menos en -s modo, no actúa como un cliente NTP completo, solo envía y recibe 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 la hora correcta. La forma en que se calcula es bastante simple:cada servidor NTP obtiene su hora de un reloj externo (por ejemplo, un receptor de radio o GPS) o de otro servidor NTP. Si un servidor obtiene su hora 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 añadida 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 raíz en segundos, que es lo que la gente suele ver, ntpclient lo muestra en microsegundos . Independientemente, un valor de 1217163 sigue siendo bastante alto. Un buen servidor NTP conoce la hora en unos pocos milisegundos; una mala en unas pocas decenas o cientos de milisegundos. El tuyo te dice que solo se puede confiar en su tiempo dentro de +/- 1.2 segundos.
En realidad, puede hacer que ntpclient se sincronice con este servidor de todos modos pasando el -x 0 o -t opción (dependiendo de la versión de ntpclient), que deshabilita las comprobaciones de cordura de NTP. Si solo necesita un tiempo más o menos preciso (dentro de unos pocos segundos), eso puede ser suficiente. Sin embargo, ntpclient está siendo bastante razonable al negarse a sincronizar con un servidor tan malo. Tu ntpq la salida en la máquina ubuntu muestra una fluctuación de cientos de milisegundos para todos sus servidores, a pesar de que tienen poca demora, lo que indica una red muy poco confiable, una conspiración de todos de los servidores para proporcionar un tiempo errático, o un problema básico de cronometraje en el propio servidor.
También me preocupa que el servidor 10.31.10.22 anuncia un refid de LOCL (reloj local indisciplinado) pero tiene un estrato de 1. Por lo general, el reloj local se ajusta 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 tiempo para el resto de la red, o está siendo disciplinado por algún programa fuera del control de NTP, en cuyo caso la mala configuración es simplemente que está publicitando el LOCL refid; debe anularse para, p. GPS o lo que sea que esté proporcionando su tiempo.
Solución 2:
Solo una respuesta parcial para "¿Qué es la dispersión?":
Un viaje de ida y vuelta NTP típico:
client | | server
t1 |------->| t2
t3 |<-------| t4
Esto produce dos valores, compensación (la diferencia de tiempo 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 offset actual de los últimos 8 paquetes recibidos, eligiendo el de menor retraso.
Los mismos 8 paquetes se utilizan para calcular la dispersión haciendo un promedio ponderado de la diferencia de estos 8 desfases con el seleccionado en el último paso, donde el retraso se usa como factor de ponderación, dando mayor peso a los retrasos más pequeños. Es una medida para la "difusión" de los valores y se utiliza para calcular la calidad de un servidor de tiempo, especialmente si tiene varios para elegir.
Solución 3:
Su dispersión y sesgo son enormes, hay un desplazamiento muy grande del reloj local a ese par. Debe comparar las compensaciones con el date local y ajuste el reloj manualmente.
Ejecute ntpd y muestre ntpq -p de un host utilizando todos los pares. Seleccionará los mejores.
Solución 4:
De acuerdo con esta documentación de Cisco, "dispersión , informado en segundos, es la máxima diferencia de tiempo de reloj que se haya observado entre el reloj local y el reloj del servidor". Con servidores ntp que no están totalmente dañados, nunca debería ocurrir una alta dispersión. El único escenario factible es cuando su cliente inicia su ntp y hasta ahora solo tiene disponible su reloj local. E incluso entonces, una dispersión tan alta como la que usted informa corresponde a relojes que están atrasados por más de dos semanas .
Debería ser suficiente para asegurarse de que el reloj local no esté demasiado adelantado al principio (incluso un par de horas sería aceptable), ya sea ajustando el reloj (¡e incluso la fecha!) en el BIOS o emitiendo ntpdate una vez antes de iniciar ntpd en el cliente.