Facebook presenta un nuevo servicio de hora

Facebook presentó un nuevo servicio de hora NTP en la dirección time.facebook.com. Según la empresa, es más preciso que otros servicios públicos de hora y no identifica a los usuarios por su dirección IP. Además, Facebook publicó en su blog de ingeniería un artículo relacionado con este servicio. (En inglés)

La razón por la que una gran empresa de TI como Facebook se interesa por los servicios de hora tiene que ver con la operación de sistemas distribuidos. Para procesar transacciones en bases de datos distribuidas o garantizar un registro correcto de eventos, varios servidores deben mantener sus relojes sincronizados con alta precisión.

Facebook compró equipo profesional de prueba de Stratum 1 (dispositivos que reciben información horaria directamente de los relojes atómicos de los satélites) y realizó un benchmark comparando ntpd, que se usaba comúnmente como servidor de hora, con chrony ( https://chrony.tuxfamily.org/ ), un daemon NTP relativamente más nuevo. ntpd mostró temporalmente un error de -10 ms justo después del arranque inicial y luego fue convergiendo gradualmente a un margen de ±1 ms, mientras que en chrony la mayoría de los errores se mantuvieron dentro de ±0.2 ms, mostrando una precisión muy superior a la de ntpd.

chrony también tiene otras ventajas. Una de ellas es que soporta marcas de tiempo por hardware. NTP, el protocolo de sincronización de hora, intenta obtener la hora actual con la mayor precisión posible calculando la diferencia de tiempo que tarda un paquete en ir y volver entre el servidor y el cliente, marcando timestamps en cada intercambio. Pero cuando no se trata de un sistema operativo de tiempo real, no se puede garantizar que la latencia de cierto procesamiento se mantenga por debajo de un nivel fijo. En NTP ocurre lo mismo, y eso se convierte en una de las causas del aumento del error al sincronizar la hora por red.

Sin embargo, algunas NIC (tarjetas de red) soportan la función de timestamp por hardware. Esta función mantiene un reloj propio en la NIC mediante hardware dedicado y procesa las marcas de tiempo allí mismo, por lo que la latencia de procesamiento es de apenas unos pocos nanosegundos. Si el entorno fuera una red local y tanto el servidor NTP como el cliente soportaran timestamp por hardware, en una situación ideal sería posible sincronizar la hora con un error menor a 1 microsegundo. En un servicio de hora real no se puede esperar tanto, porque no se trata de una red local y además puede ocurrir que la NIC del cliente no soporte timestamp por hardware, pero aun así, al combinar chrony con esta función en las pruebas, se reportó que la mayoría de los errores de sincronización quedaron dentro de ±0.1 ms.

Por eso Facebook ofrece su servicio público de hora con una configuración de chrony que tiene activado el timestamp por hardware. Mientras que otros servidores públicos de hora, como los de Google o Apple, a veces superan un error de ±2 ms, en el servicio de Facebook la mayoría de los casos se mantiene dentro de ±1 ms. Como referencia, este servicio opera con endpoints en cinco regiones distintas. Para más detalles, consulta el artículo original.

[ryuheechul]

Guau. Fue un artículo interesante. Compartieron de forma breve (?) pero detallada el esfuerzo por lograr precisión. Después de leerlo, cambié el servidor NTP de mi Mac a time3.facebook.com.

[kunggom]

Yo estoy usando time1.facebook.com. Al hacer ping, vi que los otros endpoints del 2 al 5 no responden al ping o son bastante lentos. Al configurar time1.facebook.com como servidor de tiempo en chrony, el error estimado aparece como un poco más de ±1 ms. Si configuro simplemente time.facebook.com, no logra obtener la hora.

[kunggom]

Como referencia, otros servidores de hora, por ejemplo time.google.com o time.windows.com, sin excepción muestran un error de más de 30 ms. Lo mismo pasa con pools NTP como kr.pool.ntp.org. Aun así, el servidor de hora que hasta ahora he visto con la menor desviación es ntp.postech.ac.kr, un servidor Stratum 1, y chrony lo estima en alrededor de ±5 ms.

[kunggom]

Hace poco descubrí que, si en chrony configuras time.apple.com como Pool, se seleccionan servidores NTP de alta precisión ubicados en Corea y Japón. Incluso aparecen como Stratum 1. Parece que Apple les pone receptores GPS a sus propios servidores CDN y los usa como servidores de tiempo.

[xguru]

Qué interesante y divertido. La expresión at Facebook scale ya me resulta familiar.

[kunggom]

Es algo aparte, pero veo que esta publicación no apareció en el Twitter de GeekNews. ¿Hay alguna condición específica para las noticias que publica el bot de Twitter?

[xguru]

Ah, revisándolo, parece que en la parte donde se verifica la cantidad de caracteres y se recorta antes de publicar, la URL que va al principio del contenido se convierte automáticamente en enlace, y eso hizo que se excediera el límite de caracteres y diera error en la API de Twitter :(

En Twitter, las URL se convierten siempre a algo así como 22 bytes.

Parece que habrá que corregir esta parte, snif.