Cómo se implementa Precision Time Protocol en Meta

La implementación de Precision Time Protocol (PTP) en Meta nos permite sincronizar los sistemas que impulsan nuestros productos y servicios con una precisión de nanosegundos. El predecesor de PTP, Network Time Protocol (NTP), nos brindó una precisión de milisegundos, pero a medida que escalamos a sistemas más avanzados en nuestro camino hacia la construcción de la próxima plataforma informática, el metaverso y la IA, debemos asegurarnos de que nuestros servidores mantengan el tiempo como con la mayor exactitud y precisión posible. Con PTP implementado, podremos mejorar las tecnologías y los programas de Meta, desde las comunicaciones y la productividad hasta el entretenimiento, la privacidad y la seguridad, para todos, en todas las zonas horarias y en todo el mundo.

El viaje a PTP ha sido largo, ya que hemos tenido que repensar cómo funcionan tanto el hardware como el software de cronometraje dentro de nuestros servidores y centros de datos.

Estamos compartiendo una inmersión técnica profunda en nuestra migración PTP y nuestras innovaciones que la han hecho posible.

Antes de sumergirnos en la arquitectura PTP, exploremos un caso de uso simple para una sincronización extremadamente precisa, por el bien de la ilustración.

Imagine una situación en la que un cliente escribe datos e inmediatamente intenta leerlos. En grandes sistemas distribuidos, hay muchas posibilidades de que la escritura y la lectura aterricen en diferentes nodos de back-end.

Si la lectura llega a una réplica remota que aún no tiene la última actualización, existe la posibilidad de que el usuario no vea su propia escritura:

Esto es molesto como mínimo, pero lo más importante es que viola una garantía de linealización que permite la interacción con un sistema distribuido de la misma manera que con un solo servidor.

La forma típica de resolver esto es emitir varias lecturas a diferentes réplicas y esperar una decisión de quórum. Esto no solo consume recursos adicionales, sino que también retrasa significativamente la lectura debido al largo retraso de ida y vuelta de la red.

Agregar marcas de tiempo precisas y confiables en un back-end y réplicas nos permite simplemente esperar hasta que la réplica alcance la marca de tiempo de lectura:

Esto no solo acelera la lectura, sino que también ahorra toneladas de potencia informática.

Una condición muy importante para que este diseño funcione es que todos los relojes estén sincronizados o que se conozca el desplazamiento entre un reloj y la fuente de tiempo. Sin embargo, la compensación cambia debido a la corrección constante, la deriva o las simples variaciones de temperatura. Para ello, utilizamos la noción de Ventana de Incertidumbre (WOU), donde podemos decir con una alta probabilidad dónde está el desplazamiento. En este ejemplo particular, la lectura debe bloquearse hasta la marca de tiempo de lectura más WOU.

Se podría argumentar que realmente no necesitamos PTP para eso. NTP funcionará bien. Bueno, eso también lo pensamos. Pero los experimentos que realizamos comparando nuestra implementación de NTP de última generación y una versión anterior de PTP mostraron una diferencia de rendimiento de aproximadamente 100 veces:

Hay varios casos de uso adicionales, que incluyen seguimiento de eventos, invalidación de caché, mejoras en la detección de violaciones de privacidad, compensación de latencia en el metaverso y ejecución simultánea en IA, muchos de los cuales reducirán en gran medida los requisitos de capacidad de hardware. Esto nos mantendrá ocupados durante los próximos años.

Ahora que estamos en la misma página, veamos cómo implementamos PTP a escala Meta.

Después de varias revisiones operativas y de confiabilidad, llegamos a un diseño que se puede dividir en tres componentes principales: el rack PTP, la red y el cliente.

Abróchate el cinturón: vamos a sumergirnos profundamente.

Este alberga el hardware y el software que sirven de tiempo a los clientes; el rack consta de múltiples componentes críticos, cada uno de los cuales ha sido cuidadosamente seleccionado y probado.

La antena GNSS es fácilmente uno de los componentes menos apreciados. Pero este es el lugar donde se origina el tiempo, al menos en la Tierra.

Nos esforzamos por lograr una precisión de nanosegundos. Y si el receptor GNSS no puede determinar con precisión la posición, no podrá calcular el tiempo. Tenemos que considerar seriamente la relación señal-ruido (SNR). Una antena de baja calidad o una obstrucción al cielo abierto pueden generar un alto error de desviación estándar de ubicación 3D. Para que el tiempo se determine con extrema precisión, los receptores GNSS deben ingresar al llamado modo de tiempo, que generalmente requiere un error 3D de <10 m.

Es absolutamente esencial asegurar un cielo abierto e instalar una antena estacionaria sólida. También podemos disfrutar de unas hermosas vistas:

Mientras probábamos diferentes soluciones de antena, nos llamó la atención una tecnología relativamente nueva de GNSS sobre fibra. Está libre de casi todas las desventajas: no conduce electricidad porque está alimentado por un láser a través de fibra óptica y la señal puede viajar varios kilómetros sin amplificadores.

En el interior del edificio, puede utilizar fibra estructurada y paneles de conexión LC preexistentes, lo que simplifica significativamente la distribución de la señal. Además, los retrasos de la señal de fibra óptica están bien definidos en aproximadamente 4,9 ns por metro. Lo único que queda es el retraso introducido por la RF directa a la modulación láser y los divisores ópticos, que rondan los 45 ns por caja.

Mediante la realización de pruebas, confirmamos que el retraso de la antena de extremo a extremo es determinista (normalmente unos cientos de nanosegundos) y puede compensarse fácilmente en el lado de Time Appliance.

Time Appliance es el corazón de la infraestructura de cronometraje. Aquí es donde se origina el tiempo desde el punto de vista de la infraestructura del centro de datos. En 2021, publicamos un artículo que explica por qué desarrollamos un nuevo Time Appliance y por qué las soluciones existentes no serían suficientes.

Pero esto fue principalmente en el contexto de NTP. PTP, por otro lado, trae requisitos aún más altos y restricciones más estrictas. Lo que es más importante, nos comprometimos a admitir de manera confiable hasta 1 millón de clientes por dispositivo sin afectar la exactitud y la precisión. Para lograr esto, echamos un vistazo crítico a muchos de los componentes tradicionales de Time Appliance y pensamos mucho en su confiabilidad y diversidad.

Para proteger nuestra infraestructura de un error crítico o un ataque malicioso, decidimos comenzar la diversificación desde la fuente del tiempo: la tarjeta de tiempo. La última vez, hablamos mucho sobre el diseño de la tarjeta de tiempo y las ventajas de una solución basada en FPGA. Bajo Open Compute Project (OCP), estamos colaborando con proveedores como Orolia, Meinberg, Nvidia, Intel, Broadcom y ADVA, que están implementando sus propias tarjetas de tiempo, que coinciden con la especificación OCP.

La tarjeta de tiempo es un componente crítico que requiere una configuración y supervisión especiales. Para este propósito, trabajamos con Orolia para desarrollar un software de disciplina, llamado oscilatord, para diferentes tipos de tarjetas de tiempo. Esta se ha convertido en la herramienta predeterminada para:

Efectivamente, los datos exportados desde oscilatord nos permiten decidir si Time Appliance debe recibir tráfico o debe drenarse.

Nuestro objetivo final es hacer que los protocolos como PTP se propaguen a través de la red de paquetes. Y si la tarjeta de tiempo es el corazón palpitante del dispositivo de tiempo, la tarjeta de red es la cara. Cada paquete PTP sensible al tiempo recibe una marca de tiempo del hardware por parte de la NIC. Esto significa que el reloj de hardware PTP (PHC) de la NIC debe controlarse con precisión.

Si simplemente copiamos los valores del reloj de la tarjeta de tiempo a la NIC, usando phc2sys o una herramienta similar, la precisión no será suficiente. De hecho, nuestros experimentos muestran que perderíamos fácilmente entre 1 y 2 microsegundos al pasar por PCIe, CPU, NUMA, etc. el desarrollo y el soporte para varios periféricos con esta capacidad están en progreso.

Para nuestra aplicación, dado que usamos NIC con capacidades de entrada PPS, empleamos ts2phc, que primero copia los valores del reloj y luego alinea los bordes del reloj en función de una señal de pulso por segundo (PPS). Esto requiere un cable adicional entre la salida PPS de la tarjeta de tiempo y la entrada PPS de la NIC, como se muestra en la imagen a continuación.

Supervisamos constantemente el desplazamiento y nos aseguramos de que nunca se salga de una ventana de ±50 ns entre la tarjeta de tiempo y la NIC:

También monitoreamos la interfaz de salida PPS de la NIC para que actúe como una prueba de fallas y nos aseguremos de saber realmente lo que sucede con el PHC en la NIC.

Al evaluar diferentes implementaciones de servidores PTP preexistentes, experimentamos problemas de escalabilidad con soluciones propietarias cerradas y de código abierto, incluidos los servidores PTP acelerados por FPGA que evaluamos. En el mejor de los casos, podríamos obtener alrededor de 50 000 clientes por servidor. A nuestra escala, esto significa que tendríamos que implementar muchos racks llenos de estos dispositivos.

Dado que el ingrediente secreto de PTP es el uso de marcas de tiempo de hardware, la implementación del servidor no tiene que ser un programa C altamente optimizado o incluso un dispositivo acelerado por FPGA.

Implementamos un servidor PTP de unidifusión PTPv2 escalable en Go, al que llamamos ptp4u, y lo abrimos en GitHub. Con algunas optimizaciones menores, pudimos admitir más de 1 millón de clientes simultáneos por dispositivo, lo que fue verificado de forma independiente por un dispositivo certificado IEEE 1588v2.

Esto fue posible a través del uso simple pero elegante de los canales en Go que nos permitieron pasar suscripciones entre múltiples trabajadores poderosos.

Debido a que ptp4u se ejecuta como un proceso en una máquina Linux, automáticamente obtenemos todos los beneficios, como compatibilidad con IPv6, firewall, etc., de forma gratuita.

El servidor ptp4u tiene muchas opciones de configuración, lo que le permite pasar parámetros que cambian dinámicamente, comoPrecisión del reloj PTP,Clase de reloj PTP,y uncompensación UTC— que actualmente está configurado en 37 segundos (esperamos que esto se convierta en una constante) — hasta los clientes.

Para generar con frecuencia estos parámetros, implementamos un servicio separado llamado c4u, que monitorea constantemente varias fuentes de información y compila la configuración activa para ptp4u:

Esto nos da flexibilidad y reactividad si el entorno cambia. Por ejemplo, si perdemos la señal GNSS en uno de los dispositivos de tiempo, cambiaremos ClockClass a HOLDOVER y los clientes migrarán de inmediato. También calcula ClockAccuracy de muchas fuentes diferentes, como la calidad de sincronización ts2phc, el estado del reloj atómico, etc.

Calculamos el valor de compensación UTC en función del contenido del paquete tzdata porque transmitimos el tiempo atómico internacional (TAI) a los clientes.

Queríamos asegurarnos de que nuestros dispositivos de tiempo fueran evaluados de manera constante e independiente por un dispositivo de monitoreo certificado bien establecido. Afortunadamente, ya hemos avanzado mucho en el espacio NTP con Calnex, y estábamos en condiciones de aplicar un enfoque similar a PTP.

Colaboramos con Calnex para tomar su dispositivo de campo y reutilizarlo para el uso del centro de datos, lo que implicó cambiar el factor de forma físico y agregar soporte para funciones como IPv6.

Conectamos la salida PPS de la NIC de Time Appliance al Calnex Sentinel, lo que nos permite monitorear el PHC de la NIC con una precisión de nanosegundos.

Exploraremos el monitoreo con gran detalle en "Cómo monitoreamos la arquitectura PTP", a continuación.

El protocolo PTP admite el uso de modos de unidifusión y multidifusión para la transmisión de mensajes PTP. Para implementaciones de grandes centros de datos, se prefiere la unidifusión a la multidifusión porque simplifica significativamente el diseño de la red y los requisitos de software.

Echemos un vistazo a un flujo de unidifusión PTP típico:

Un cliente inicia la negociación (solicitando transmisión unicast). Por lo tanto, debe enviar:

Esquemáticamente (solo para la ilustración), se verá así:

Inicialmente consideramos aprovechar los relojes de límite en nuestro diseño. Sin embargo, los relojes de límite vienen con varias desventajas y complicaciones:

Para evitar esta complejidad adicional, decidimos confiar únicamente en relojes transparentes PTP.

Los relojes transparentes (TC) permiten a los clientes tener en cuenta las variaciones en la latencia de la red, lo que garantiza una estimación mucho más precisa del desplazamiento del reloj. Cada conmutador del centro de datos en la ruta entre el cliente y el servidor de tiempo informa el tiempo que cada paquete PTP pasa en tránsito por el conmutador mediante la actualización de un campo en la carga útil del paquete, el Campo de corrección (CF, por sus siglas en inglés).

Los clientes PTP (también denominados relojes ordinarios u OC) calculan el retraso medio de la ruta de la red y las compensaciones de reloj a los servidores de tiempo (relojes de gran maestro o GM) utilizando cuatro marcas de tiempo (T1, T2, T3 y T4) y dos valores de campo de corrección (CFa y CFb), como se muestra en el siguiente diagrama:

Para comprender el impacto de un solo reloj transparente deshabilitado en el camino entre el cliente y un servidor, podemos examinar los registros:

Podemos ver que el retraso de la ruta explota, a veces incluso volviéndose negativo, lo que no debería suceder durante las operaciones normales. Esto tiene un impacto dramático en el desplazamiento, moviéndolo de ±100 nanosegundos a -400 microsegundos (más de 4000 veces la diferencia). Y lo peor de todo, este desplazamiento ni siquiera será exacto, porque los cálculos del retardo medio de la ruta son incorrectos.

Según nuestros experimentos, los conmutadores modernos con grandes búferes pueden retrasar los paquetes hasta un par de milisegundos, lo que resultará en cientos de microsegundos de error en el cálculo del retraso de la ruta. Esto impulsará los picos de compensación y será claramente visible en los gráficos:

La conclusión es que ejecutar PTP en centros de datos en ausencia de TC conduce a una asimetría impredecible e inexplicable en el tiempo de ida y vuelta. Y lo peor de todo: no habrá una forma sencilla de detectarlo. 500 microsegundos pueden no parecer mucho, pero cuando los clientes esperan que un WOU sea de varios microsegundos, esto puede conducir a una violación de SLA.

La marca de tiempo del paquete entrante es una función relativamente antigua admitida por el kernel de Linux durante décadas. Por ejemplo, las marcas de tiempo del software (núcleo) han sido utilizadas por los demonios NTP durante años. Es importante comprender que las marcas de tiempo no se incluyen en la carga útil del paquete de forma predeterminada y, si es necesario, la aplicación del usuario debe colocarlas allí.

Leer la marca de tiempo RX desde el espacio del usuario es una operación relativamente simple. Cuando llega el paquete, la tarjeta de red (o un kernel) marcará la hora de este evento e incluirá la marca de tiempo en el mensaje de control del socket, lo cual es fácil de llevarse bien con el paquete en sí llamando a una llamada al sistema recvmsg con el indicador MSG_ERRQUEUE establecido.

Para la marca de tiempo del hardware TX es un poco más complicado. Cuando se ejecuta sendto syscall, no conduce a una salida inmediata del paquete ni a la generación de una marca de tiempo de TX. En este caso, el usuario tiene que sondear el socket hasta que el núcleo coloque con precisión la marca de tiempo. A menudo tenemos que esperar varios milisegundos, lo que naturalmente limita la velocidad de envío.

Las marcas de tiempo de hardware son el ingrediente secreto que hace que PTP sea tan preciso. La mayoría de las NIC modernas ya tienen compatibilidad con marcas de tiempo de hardware donde el controlador de la tarjeta de red completa la sección correspondiente.

Es muy fácil verificar el soporte ejecutando el comando ethtool:

Todavía es posible usar PTP con marcas de tiempo de software (núcleo), pero no habrá garantías sólidas sobre su calidad, precisión y exactitud.

También evaluamos esta posibilidad e incluso consideramos implementar un cambio en el kernel para "falsificar" las marcas de tiempo del hardware con software donde las marcas de tiempo del hardware no están disponibles. Sin embargo, en un host muy ocupado, observamos que la precisión de las marcas de tiempo del software saltó a cientos de microsegundos y tuvimos que abandonar esta idea.

ptp4l es un software de código abierto capaz de actuar tanto como cliente PTP como servidor PTP. Si bien tuvimos que implementar nuestra propia solución de servidor PTP por razones de rendimiento, decidimos quedarnos con ptp4l para el caso de uso del cliente.

Las pruebas iniciales en el laboratorio revelaron que ptp4l puede proporcionar una excelente calidad de sincronización lista para usar y alinear el tiempo en los PHC en la red local hasta decenas de nanosegundos.

Sin embargo, a medida que comenzamos a ampliar nuestra configuración, comenzaron a surgir algunos problemas.

En un ejemplo particular, comenzamos a notar "picos" ocasionales en el desplazamiento. Después de una inmersión profunda, identificamos las limitaciones fundamentales de hardware de una de las NIC más populares del mercado:

Esto finalmente condujo a que las marcas de tiempo legítimas fueran reemplazadas por marcas de tiempo provenientes de otros paquetes. Pero lo que empeoró mucho las cosas: el controlador de la NIC trató de ser demasiado inteligente y colocó las marcas de tiempo del software en la sección de marca de tiempo del hardware del mensaje de control del socket sin decírselo a nadie.

Es una limitación de hardware fundamental que afecta a una gran parte de la flota y que es imposible de solucionar.

Tuvimos que implementar un filtro de valores atípicos compensados, que cambió el comportamiento de PI servo y lo hizo con estado. El resultado fue que se descartaron valores atípicos ocasionales y se estableció la frecuencia media durante el micro-remanente:

Si no fuera por este filtro, ptp4l habría dirigido la frecuencia de PHC realmente alta, lo que resultaría en varios segundos de oscilación y mala calidad en la Ventana de Incertidumbre que generamos a partir de él.

Otro problema surgió del diseño de BMCA. El propósito de este algoritmo es seleccionar el mejor dispositivo de tiempo cuando hay varios para elegir en el ptp4l.conf. Lo hace comparando varios atributos proporcionados por los servidores de hora en los mensajes de anuncio:

El problema se manifiesta cuando todos los atributos antes mencionados son iguales. BMCA utiliza la dirección MAC de Time Appliance como factor de desempate, lo que significa que, en condiciones normales de funcionamiento, un Time Server atraerá todo el tráfico de clientes.

Para combatir esto, introdujimos el llamado "fragmento" con diferentes clientes PTP asignados a diferentes subgrupos de Time Appliances de todo el grupo.

Esto solo solucionó parcialmente el problema con un servidor en cada subgrupo tomando toda la carga para ese grupo. La solución fue permitir que los clientes expresaran una preferencia, por lo que introdujimos Priority3 en los criterios de selección justo encima del desempate de la dirección MAC. Esto significa que los clientes configurados para usar los mismos dispositivos de tiempo pueden preferir diferentes servidores.

Cliente 1:

[unicast_master_table]

UDPv6 time_server1 1

UDPv6 time_server2 2

UDPv6 time_server3 3

Cliente 2:

[unicast_master_table]

UDPv6 time_server2 1

UDPv6 time_server3 2

UDPv6 time_server1 3

Esto garantiza que podamos distribuir la carga de manera uniforme en todos los dispositivos Time en condiciones normales de funcionamiento.

Otro desafío importante al que nos enfrentamos fue asegurarnos de que PTP funcionara con NIC de múltiples hosts: múltiples hosts que comparten la misma interfaz de red física y, por lo tanto, un solo PHC. Sin embargo, ptp4l no tiene conocimiento de esto y trata de disciplinar al PHC como si no hubiera otros vecinos.

Algunos fabricantes de NIC desarrollaron el llamado modo de "ejecución libre" en el que ptp4l solo disciplina la fórmula dentro del controlador del kernel. El PHC real no se ve afectado y sigue funcionando libremente. Este modo da como resultado una precisión ligeramente peor, pero es completamente transparente para ptp4l.

Otros fabricantes de NIC solo admiten un modo de "reloj en tiempo real", cuando el primer host en obtener el bloqueo en realidad disciplina el PHC. La ventaja aquí es una calibración más precisa y un remanente de mayor calidad, pero conduce a un problema separado con la ejecución de ptp4l en los otros hosts que usan la misma NIC, ya que los intentos de sintonizar la frecuencia de PHC no tienen impacto, lo que lleva a cálculos de frecuencia y compensación de reloj inexactos.

Para describir la configuración del centro de datos, desarrollamos y publicamos un perfil PTP, que refleja los casos extremos antes mencionados y muchos más.

Estamos evaluando la posibilidad de utilizar un cliente PTP alternativo. Nuestros principales criterios son:

Estamos evaluando el cliente PTP de Timebeat y, hasta ahora, parece muy prometedor.

En el protocolo PTP, realmente no importa a qué hora nos propagamos, siempre y cuando transmitamos un desplazamiento UTC a los clientes. En nuestro caso, es el Tiempo Atómico Internacional (TAI), pero algunas personas pueden elegir UTC. Nos gusta pensar en el tiempo que proporcionamos como un contador que se incrementa continuamente.

En este punto, no estamos disciplinando el reloj del sistema y ptp4l se usa únicamente para disciplinar el PHC de la NIC.

La sincronización de los PHC en la flota de servidores es buena, pero no es beneficiosa a menos que haya una forma de leer y manipular estos números en el cliente.

Para este propósito, desarrollamos una API simple y liviana llamada fbclock que recopila información de PHC y ptp4l y expone información de ventana de incertidumbre fácil de digerir:

A través de un ioctl PTP_SYS_OFFSET_EXTENDED muy eficiente, fbclock obtiene las marcas de tiempo actuales del PHC, los datos más recientes de ptp4l y luego aplica una fórmula matemática para calcular la ventana de incertidumbre (WOU):

Como puede ver, la API no devuelve la hora actual (también conocida como time.Now()). En su lugar, devuelve una ventana de tiempo que contiene la hora real con un grado de probabilidad muy alto. En este ejemplo particular, sabemos que nuestra ventana de incertidumbre es de 694 nanosegundos y la hora es entre (TAI) el jueves 02 de junio de 2022 a las 17:44: 08:711023134 y jueves 02 de junio de 2022 17:44:08:711023828.

Este enfoque permite a los clientes esperar hasta que se pase el intervalo para garantizar el pedido exacto de la transacción.

Medir la precisión de la hora o (Ventana de incertidumbre) significa que junto con el valor de hora entregado, se presenta una ventana (un valor más/menos) que garantiza incluir la hora real con un alto nivel de certeza.

La certeza que debemos tener está determinada por la importancia de que el tiempo sea correcto y esto depende de la aplicación específica.

En nuestro caso, esta certeza debe ser superior al 99,9999 % (6-9 s). Con este nivel de confiabilidad, puede esperar menos de 1 error en 1,000,000 de mediciones.

La estimación de la tasa de error utiliza la observación de la historia de los datos (histograma) para ajustar una función de distribución de probabilidad (PDF). A partir de la función de distribución de probabilidad se puede calcular la varianza (sacar una raíz cuadrada y obtener la desviación estándar) y de allí será una simple multiplicación para llegar a la estimación de la distribución en función de su valor.

A continuación se muestra un histograma tomado de la medición de compensación de ptp4l que se ejecuta en el reloj ordinario.

Para estimar la varianza total (E2E) es necesario conocer la varianza del error de tiempo acumulado por el servidor de tiempo hasta la NIC del nodo final. Esto incluye GNSS, reloj atómico y tarjeta de tiempo PHC a NIC PHC (ts2phc). El fabricante proporciona la variación del error GNSS. En el caso del UBX-F9T son unos 12 nanosegundos. Para el reloj atómico, el valor depende del umbral de disciplina que hayamos establecido. Cuanto más estricto sea el umbral de disciplina, menor será la varianza de compensación pero menor el rendimiento remanente. En el momento de realizar este experimento, la varianza del error del reloj atómico se ha medido en 43 ns (desviación estándar, estándar). Finalmente, la herramienta ts2phc aumenta la varianza en 30 ns (estándar), lo que da como resultado una varianza total de 52 ns.

Los resultados observados coinciden con la varianza calculada obtenida por la "Ley de la suma de la varianza".

Según la ley de la suma de las varianzas, todo lo que tenemos que hacer es sumar todas las varianzas. En nuestro caso, sabemos que el error E2E total del observador (medido a través de Calnex Sentinel) es de aproximadamente 92 ns.

Por otro lado para nuestra estimación, podemos tener lo siguiente:

Variación E2E estimada = [Variación GNSS + Variación MAC + Variación ts2phc] + [Variación de compensación PTP4L] = [Variación del servidor de tiempo] + [Variación del reloj ordinario]

Conectando los valores:

Varianza E2E estimada = (12ns 2) + (43ns2) + (52ns2) + (61ns2) = 8418, que corresponde a 91,7ns

Estos resultados muestran que al propagar la varianza del error hacia abajo en el árbol del reloj, la varianza del error E2E se puede estimar con una buena precisión. La varianza del error E2E se puede utilizar para calcular la ventana de incertidumbre (WOU) según la siguiente tabla.

Simplemente, al multiplicar la varianza del error E2E estimada en 4.745, podemos estimar la ventana de incertidumbre para la probabilidad de 6-9s.

Para nuestro sistema dado, la probabilidad de 6-9s es de aproximadamente 92ns x 4,745 = 436ns

Esto significa que dado un tiempo informado por PTP, considerando un tamaño de ventana de 436 ns alrededor del valor, se garantiza incluir el tiempo real con una confianza de más del 99.9999%.

Si bien todo lo anterior parece lógico y excelente, hay una gran suposición allí. La suposición es que la conexión al servidor de tiempo abierto (OTS) está disponible y todo está en modo de operación normal. Muchas cosas pueden salir mal, como que el OTS se apague, el interruptor se apague, los mensajes de sincronización no se comporten como se supone que deben hacerlo, algo intermedio decida despertar las llamadas de guardia, etc. En tal situación, el cálculo del límite de error debería entrar en el modo de reserva. Lo mismo se aplica a la OTS cuando el GNSS está inactivo. En tal situación, el sistema aumentará la ventana de incertidumbre en función de una tasa compuesta. La tasa se estimará en función de la estabilidad del oscilador (varianza de desplazamiento) durante las operaciones normales. En el OTS, la tasa compuesta se ajusta mediante el control de telemetría preciso del sistema (temperatura, vibración, etc.). Hay una buena cantidad de trabajo en términos de calibración de coeficientes aquí y obtener el mejor resultado y todavía estamos trabajando en esos ajustes finos.

Durante los períodos de disponibilidad de sincronización de red, el servo ajusta constantemente la frecuencia del reloj local en el lado del cliente (suponiendo que el paso inicial resultó en convergencia). Una interrupción en la sincronización de la red (por la pérdida de conexión con el servidor de tiempo o por la caída del mismo servidor de tiempo) dejará al servo con un último valor de corrección de frecuencia. Como resultado, dicho valor no pretende ser una estimación de la precisión del reloj local, sino un ajuste de frecuencia temporal para reducir el error de tiempo (offset) medido entre el cline y el servidor de tiempo.

Por lo tanto, primero es necesario tener en cuenta los períodos de pérdida de sincronización y utilizar la mejor estimación de la corrección de frecuencia (generalmente, el promedio de desplazamiento de los valores de corrección anteriores) y, en segundo lugar, tener en cuenta el aumento del límite de error observando el último valor de corrección y comparándolo. con el promedio móvil de los valores de corrección anteriores.

El monitoreo es una de las partes más importantes de la arquitectura PTP. Debido a la naturaleza y el impacto del servicio, dedicamos bastante tiempo a trabajar en las herramientas.

Trabajamos con el equipo de Calnex para crear la API HTTP de Sentinel, que nos permite administrar, configurar y exportar datos desde el dispositivo. En Meta, creamos y abrimos una herramienta de línea de comando API que permite interacciones amigables con humanos y scripts.

Al usar Calnex Sentinel 2.0, podemos monitorear tres métricas principales por dispositivo de tiempo: NTP, PTP y PPS.

Esto nos permite notificar a los ingenieros sobre cualquier problema con los dispositivos y detectar con precisión dónde está el problema.

Por ejemplo, en este caso, tanto el monitoreo de PTP como el de PPS tienen una variación de aproximadamente menos de 100 nanosegundos durante 24 horas cuando NTP se mantiene dentro de los 8 microsegundos.

Para monitorear nuestra configuración, implementamos y abrimos una herramienta llamada ptpcheck. Tiene muchos subcomandos diferentes, pero los más interesantes son los siguientes:

El subcomando de cliente proporciona un estado general de un cliente ptp. Informa la hora de recepción del último mensaje de sincronización, la compensación del reloj con el servidor de hora seleccionado, el retraso medio de la ruta y otra información útil:

Subcomando de cliente que permite consultar una API de fbclock y obtener una ventana de incertidumbre actual:

El monitoreo de clientes al estilo Chrony, permite ver todos los Servidores de Tiempo configurados en el archivo de configuración del cliente, su estado y calidad de tiempo.

Subcomando del servidor, permite leer un resumen de la Tarjeta de tiempo.

Por ejemplo, podemos ver que la última corrección en la tarjeta de tiempo fue de solo 1 nanosegundo.

Este subcomando nos permite obtener una diferencia entre dos PHC cualesquiera:

En este caso particular, la diferencia entre la tarjeta de tiempo y una NIC en un servidor es de -15 nanosegundos.

Es bueno activar el monitoreo de forma periódica o bajo demanda, pero queremos ir más allá. Queremos saber lo que el cliente está experimentando realmente. Con este fin, incorporamos varios cubos dentro de la API de fbclock basados ​​en contadores atómicos, que se incrementan cada vez que el cliente realiza una llamada a una API:

Esto nos permite ver claramente cuándo el cliente experimenta un problema y, a menudo, incluso antes de que el cliente lo note.

El protocolo PTP (y ptp4l en particular) no tiene un proceso de selección de quórum (a diferencia de NTP y chrony). Esto significa que el cliente elige y confía en el servidor de tiempo en función de la información proporcionada a través de los mensajes de anuncio. Esto es cierto incluso si el propio servidor de hora es incorrecto.

Para tales situaciones, hemos implementado una última línea de defensa llamada verificación de linearizabilidad.

Imagine una situación en la que un cliente está configurado para usar tres servidores de tiempo y el cliente está suscrito a un servidor de tiempo defectuoso (por ejemplo, el servidor de tiempo 2):

En esta situación, el cliente PTP pensará que todo está bien, pero la información que proporciona a la aplicación que consume tiempo será incorrecta, ya que la ventana de incertidumbre se desplazará y, por lo tanto, será inexacta.

Para combatir esto, en paralelo, el fbclock establece comunicación con los servidores de tiempo restantes y compara los resultados. Si la mayoría de las compensaciones son altas, esto significa que el servidor que sigue nuestro cliente es el atípico y el cliente no es linealizable, incluso si la sincronización entre el servidor de tiempo 2 y el cliente es perfecta.

Creemos que PTP se convertirá en el estándar para mantener el tiempo en las redes informáticas en las próximas décadas. Es por eso que lo estamos desplegando en una escala sin precedentes. Tuvimos que analizar de manera crítica toda nuestra pila de infraestructura, desde la antena GNSS hasta la API del cliente, y en muchos casos incluso reconstruimos las cosas desde cero.

A medida que continuamos con la implementación de PTP, esperamos que más proveedores que producen equipos de red aprovechen nuestro trabajo para ayudar a traer nuevos equipos compatibles con PTP a la industria. Hemos abierto la mayor parte de nuestro trabajo, desde nuestro código fuente hasta nuestro hardware, y esperamos que la industria se una a nosotros para traer PTP al mundo. Todo esto se ha hecho en nombre de impulsar el rendimiento y la confiabilidad de las soluciones existentes, pero también con miras a abrir nuevos productos, servicios y soluciones en el futuro.

Queremos agradecer a todos los involucrados en este esfuerzo, desde los equipos internos de Meta hasta los proveedores y fabricantes que colaboran con nosotros. Un agradecimiento especial a Andrei Lukovenko, quien conectó a los entusiastas del tiempo.

Este viaje solo está terminado en un uno por ciento.