¿Hay disponible material de investigación sobre la precisión de NTP?

Hasta donde sé, la precisión de la sincronización NTP depende en gran medida de la red. He visto algunos números de 50 microsegundos a "menos de un segundo" en Internet. Bueno, esta es una gran diferencia.

Creo que la dependencia de la precisión es una gran pregunta para estudiar, pero hasta ahora no pude encontrar ningún material, lo que establece claramente que, por ejemplo, alguna configuración particular otorga esa precisión particular.

Se dice en http://www.ntp.org/ntpfaq/NTP-s-algo.htm :

Se requiere una diferencia de tiempo de menos de 128 ms entre el servidor y el cliente para mantener la sincronización NTP. La precisión típica en Internet varía de aproximadamente 5 ms a 100 ms, posiblemente variando con los retrasos de la red. Una encuesta reciente [2] sugiere que el 90% de los servidores NTP tienen retrasos en la red por debajo de 100 ms, y aproximadamente el 99% se sincronizan en un segundo con respecto al par de sincronización.

Con la sincronización PPS, se puede lograr una precisión de 50 µs y una estabilidad por debajo de 0.1 PPM en una PC Pentium (ejecutando Linux, por ejemplo).

Eso es algo, pero ¿tal vez hay un análisis más exhaustivo sobre el tema?

Nadie puede garantizar qué tan bien funcionará NTP en su red, porque nadie sabe qué tan bien conectada está su red a Internet y a los servidores de reloj en ella. Sin embargo, de acuerdo con la página del algoritmo de disciplina de reloj en ntp.org

Si se deja funcionando continuamente, un cliente NTP en una LAN rápida en un entorno doméstico o de oficina puede mantener la sincronización nominalmente en un milisegundo. Cuando las variaciones de temperatura ambiente son inferiores a un grado Celsius, la frecuencia del oscilador del reloj se disciplina dentro de una parte por millón (PPM), incluso cuando el desplazamiento de la frecuencia nativa del oscilador del reloj es de 100 PPM o más.

Tenga en cuenta que la latencia grande pero estable entre su LAN y los servidores de reloj de Internet no tiene un efecto tan malo en la precisión como la latencia altamente variable.

No dice de dónde obtuvo las estimaciones anteriores ('50 microsegundos a ... "menos de un segundo" '), por lo que no puedo comentar sobre ellas, pero en mi experiencia 50us es poco probable a menos que tenga un archivo adjunto directamente fuente de reloj, y 1 es poco probable a menos que tenga un trozo de cadena húmeda que lo conecte a Internet y esté utilizando servidores ascendentes en la Antártida.

Editar : el texto que ahora cita en su pregunta proporciona un puntero a un documento que, en 1999, estableció que el 99% de los servidores ntp se sincronizan en un segundo. Afortunadamente, hay trabajos más recientes; En este artículo, algunos autores de la Universidad Federal de Paraná, Brasil, repitieron el experimento en 2005 y encontraron (si entiendo correctamente su Fig. 1) que al norte del 99%, más como el 99.5%, de los servidores ahora tienen compensaciones inferiores a 100 ms, y ese 90% tiene compensaciones de menos de 10 ms. Esto encaja bastante bien con mis experiencias (ver arriba).

Edición 2 : una última arruga: todos estos estudios no investigan qué tan preciso es el reloj local, sino en qué medida difiere del reloj de referencia aguas arriba. Es evidente que no son lo mismo. Pero el primero es incognoscible; para saber qué tan mal está su reloj, debe saber exactamente qué hora es, y si lo supiera, ¿por qué habría configurado mal su reloj en primer lugar? Solo tenga en cuenta que lo que miden estos estudios no es la diferencia entre el reloj local y la hora absoluta, sino entre el reloj local y el reloj de referencia.

¿Que problema estas tratando de resolver?

La solución que he encontrado para entornos que requieren más precisión que NTP es el Protocolo de tiempo de precisión (PTP) . Lo he tenido en computación científica y aplicaciones de computación financiera. Sin embargo, hay compensaciones .

Ver también: sincronización de tiempo ptp en centos6 / rhel

Algunas otras cosas que vale la pena mencionar:

• Tendrá suerte de obtener <100 ms de fluctuación de reloj en una máquina virtual, por lo que todo lo siguiente es para un host físico
• El jitter por debajo de los 100 ms es casi inconmensurable para casi todas las tareas y se puede lograr fácilmente a través de Internet
• Es posible que se necesite una fluctuación de fase inferior a 30 ms para algunos entornos de servicio generales (lo necesitaba para la correlación de registros en un trabajo anterior), y se logra fácilmente utilizando servidores NTP en el mismo continente donde la conexión no es a través de enlaces de "consumidor" (por ejemplo, no satélite , ADSL, DOCSIS, GPON, UMTS / LTE / HSPA / etc.)
• Para una precisión absoluta por debajo de esto, debe instalar servidores NTP de hardware de un proveedor de calidad (por ejemplo, Symmetricom)
• Se puede lograr fácilmente un acuerdo local de menos de 10 ms (a menudo menos de 1 ms) simplemente con un trío (se puede hacer con menos, pero hay razones para usar tres o cinco) dentro del mismo centro de datos lo suficiente para prácticamente todas las aplicaciones que no son de ciencia

Intereses adquiridos de mi parte: soy un agente de Meinberg :-)

Sí, NTP puede lograr una precisión de extremo a extremo de hasta aprox. 50 us (eso es microsegundos) de jitter, si sincroniza un "cliente" de Linux en bare metal con Chrony o ntpd, a un servidor NTP basado en Linux disciplinado por un GPS, reloj atómico local o alguna fuente de este tipo.

En la máquina que tiene un GPS local (con una interconexión PPS), probablemente verá 0-2 microsegundos de desplazamiento, entre la instancia de ntpd que se ejecuta en el sistema operativo y la entrada del controlador de reconexión PPS.

Los 50 us residuales "de extremo a extremo a través de una LAN" son el resultado de varias etapas de almacenamiento en búfer, latencia IRQ variable, otro tráfico que interfiere en la LAN y en los buses de la computadora involucrados y demás. 50 us significa una LAN con muy poco tráfico. Incluso un solo interruptor puede agregar algunos microsegundos de fluctuación de fase, y los interruptores de gama alta con características complejas agregan más latencia y fluctuación de fase. En otras palabras, puede ser bastante difícil alcanzar esos 50 microsegundos en las condiciones del mundo real en alguna LAN práctica.

De manera similar, esos cca <2us del desplazamiento de PPS resultan solo de la incertidumbre de latencia IRQ y la fluctuación de latencia general del bus en el hardware de PC con buen comportamiento.

Tenga en cuenta que NTP y sus implementaciones ntpd y Chrony ciertamente miden el tiempo de ida y vuelta de las transacciones de NTP y restan (suman, en realidad) la mitad de ese viaje de ida y vuelta, como una medida para filtrar la latencia de transporte sistemática (unidireccional). También realizan un rechazo atípico, consenso de quórum, elección de sistema y cualquier demonio NTP filtra las respuestas que recibe a sus consultas aguas arriba. Como han dicho otros, los milisegundos que ves en Ping y Traceroute no compensan directamente tu reloj local. Lo que importa es la variabilidad de la transacción de ida y vuelta, es decir, otro tráfico en la ruta a su servidor NTP ascendente. Ntpq -p es tu amigo.

Un receptor GPS básico para uso de temporización, con un TCXO, puede tener entre 100 y 200 ns de fluctuación residual + desplazamiento en su salida PPS. Suficientemente bueno para NTP, siempre que el GPS permanezca bloqueado. (El rendimiento remanente no es muy bueno con los TCXO). Un GPS de sincronización de calidad con un OCXO puede estar dentro de los 100 ns, tal vez más como 10-30 ns de error residual (compensación del UTC global).

Tenga en cuenta que los satélites reales que vuelan por encima y le transmiten a través de una atmósfera pueden ser un juego un poco más difícil para el receptor, que la evaluación comparativa en un laboratorio con un generador de GPS.

PTP es un martillo. Necesita soporte HW en el gran maestro, y en los esclavos, y en cualquier interruptor, pero si obtiene todo eso, es posible que existan compensaciones residuales de hasta dos dígitos de nanosegundos. Personalmente, he visto esto en ptp4l ejecutándose con una NIC i210 que tiene soporte HW (marca de tiempo con una resolución de nanosegundos).

El chip i210 es una maravilla. Tiene 4 pines de uso general que se pueden usar para ingresar o emitir una señal PPS. La placa NIC de complemento Intel de referencia con i210 (y sus versiones OEM de varios grandes proveedores) viene equipada con un encabezado de pin que le da acceso a al menos 2 de esos pines GPIO (SDP son llamados por Intel). Además de implementar un puerto PTP grandmaster, la entrada PPS se puede aprovechar para marcar con precisión el tiempo en la captura de paquetes. Necesita una fuente precisa de PPS y una pieza de software personalizada para ejecutar un servo loop, ajustando el PHC del i210 al PPS externo. En mi plataforma de prueba, esto resultó en ns de un solo dígito (por iteración de 1 s) de compensación residual. Esta es la precisión que obtienes en tus marcas de tiempo de captura, si ejecuta un tcpdump o wireshark reciente en un núcleo Linux moderno (todo el software necesita soporte para una resolución de nivel de nanosegundos). Mejor aún: hice todo el camino y construí un sintetizador PLL simple para producir 25 MHz para los relojes NIC, bloqueado a una referencia precisa de 10MHz aguas arriba. Después de eso, el desplazamiento residual en el servo loop de mi equipo de captura de paquetes cayó a un cero limpio (una prueba de que mi referencia de 10 MHz está sincronizada en fase con el PPS de esa misma caja de GPS).

Tenga en cuenta que los grandes maestros PTP pueden especificarse para proporcionar marcas de tiempo con una granularidad real por 8 ns (en un tipo de datos con resolución de 1 ns). Esto tiene sentido: Gigabit Ethernet tiende a usar un reloj de 125 MHz, que se usa como reloj de bytes en el interior del MAC, este reloj probablemente también se usa en el GMII, y también es el reloj de símbolo en 1000Base-TX metálico (cuatro pares en paralelo, 2 bits por símbolo por par). Entonces, a menos que esté utilizando 1000Base-FX (fibra óptica) con SERDES y una implementación extremista de la unidad de marca de tiempo HW en el PHY que funciona en bits SERDES individuales, esos 8 ns son todo lo que puede esperar de manera realista en Gigabit Ethernet. Algunas hojas de datos de chips (con soporte PTP) incluso afirman que la ruta de datos MII no está libre de almacenamiento en búfer y que puede surgir cierta fluctuación desde allí.

Los paquetes PTP en realidad contienen marcas de tiempo almacenadas en un tipo de datos que permite una resolución profunda por debajo de los nanosegundos. Pero el "campo fraccional sub-nanosegundo" actualmente no se utiliza habitualmente. AFAIR solo el proyecto White Rabbit (relacionado con el CERN, el centro de investigación suizo) ha implementado precisión de sub-ns hasta ahora.

PTP también está disponible en software puro, sin aceleración HW. En ese caso, para un GM basado en SW y un cliente basado en SW, espere obtener una inestabilidad residual similar a la de NTP, es decir, aproximadamente 50 us en una LAN dedicada pero no consciente de PTP. Recuerdo haber obtenido una precisión de menos de un microsegundo de un gran maestro HW en una interconexión directa (sin interruptor intermedio) y un cliente solo SW (en una NIC de PC PTP no consciente). En comparación con NTP, el servo del PTP converge mucho más rápido.

Mientras hacía algunos "deberes", se me ocurrió recientemente que el transporte de PPS o señales de tiempo "discretas" similares sobre rutas de fibra óptica de área amplia puede ser susceptible al "desplazamiento" del tiempo de propagación dependiente de la temperatura. Y aunque no tengo forma de probar esto experimentalmente, algunas fuentes en las redes citan cifras entre 40 y 76 picosegundos por km y Kelvin. Tenga en cuenta que si bien este tipo de "desplazamiento térmico" es imposible de mitigar "en banda" en la transmisión PPS simplex, PTP compensaría esto inherentemente, en función de sus mediciones de retardo de ruta estándar (que depende de la transmisión dúplex completa).

Esto en cuanto a una visión general de cómo son las "precisiones", en diferentes tecnologías / interfaces de temporización. Qué nivel de precisión es lo suficientemente bueno para usted, eso depende de su aplicación, de sus necesidades reales.