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.