Entrevista general: ¿Cómo elegir entre NTP, PTP y relojes monotónicos?

Planteamiento y alcance

Varios servidores deben registrar horas de eventos comparables, mientras que algunos servicios también miden plazos límite y latencia. Explique qué resuelven NTP, PTP y un reloj monotónico local al proceso; luego, proponga el despliegue, el comportamiento ante la pérdida de sincronización y la verificación. Asuma un retraso de red variable, reinicios de nodos y que la sincronización de tiempo no puede tratarse como consistencia causal.

Qué evalúa el entrevistador

La señal clave es separar la hora de reloj de pared (wall-clock) comparable, el tiempo transcurrido local y la causalidad de los eventos. Una respuesta sólida solicita primero el presupuesto de precisión y el límite de la red, para luego ubicar a NTP en la sincronización general o de red amplia, a PTP en una LAN controlada con marcas de tiempo por hardware, y a un reloj monotónico en la medición de tiempos de espera. No afirma que PTP sea automáticamente más preciso en todas partes.

Aclaraciones antes de responder

1. ¿Cuál es el desfase máximo tolerado? Las marcas de tiempo de auditoría de milisegundos suelen ajustarse a NTP; el control de microsegundos es donde PTP y el sellado de tiempo por hardware merecen evaluación.
2. ¿Está controlada la red, los conmutadores admiten IEEE 1588 y se dispone de relojes de límite (boundary) o transparentes? Sin ellos, es posible que las premisas de PTP no se cumplan.
3. ¿Se utiliza el tiempo para ordenamiento, plazos límite, firmas o evidencia de cumplimiento? Los plazos límite utilizan tiempo monotónico; el ordenamiento entre nodos todavía necesita números de secuencia, versiones o relojes lógicos.
4. ¿Qué sucede cuando desaparece la fuente de tiempo ascendente: detener escrituras, degradar o continuar? La respuesta determina el tiempo de retención (holdover), los umbrales de alerta y las etiquetas de datos.

Diseño recomendado y deducción

Construya una jerarquía: un pequeño conjunto de GPS, relojes atómicos o fuentes ascendentes de confianza alimenta a los servidores NTP regionales, y los hosts ordinarios disciplinan sus relojes de pared con NTP. Los intercambios de NTP deben tener en cuenta el retraso de ida y vuelta (round-trip delay) y la asimetría de la ruta; por lo tanto, supervise el desfase, el error de frecuencia, el retraso de ida y vuelta, el stratum y la antigüedad de la última sincronización en lugar de verificar únicamente un servicio en ejecución.

PTP propaga un reloj maestro principal (grandmaster) a través de conmutadores y puede utilizar marcas de tiempo por hardware para reducir los errores de programación del SO y de colas en la NIC. En una LAN controlada con relojes de límite o transparentes y terminales con soporte de hardware, puede satisfacer un presupuesto de error más estricto que NTP. A través de la Internet pública o rutas de nube variables, verifique el soporte real de los dispositivos y la red antes de prometer esa precisión.

wall_now = CLOCK_REALTIME      # calendar, logs, cross-node timestamps
elapsed = CLOCK_MONOTONIC      # deadlines, retries, latency measurement
deadline = monotonic_start + timeout

Un reloj monotónico no retrocede cuando NTP disciplina el tiempo de pared, por lo que es apropiado para cálculos de tiempo transcurrido. Linux documenta semánticas distintas para CLOCK_REALTIME y CLOCK_MONOTONIC. Incluso un reloj de pared bien sincronizado es inseguro para un tiempo de espera de 30 segundos porque la corrección puede dar un salto (step) o ajustar gradualmente su velocidad (slew).

Alternativas y compensaciones

NTP es sencillo de desplegar, funciona a través de redes enrutadas y cuenta con herramientas operativas maduras; su error depende de la ruta y del sellado de tiempo del host. PTP puede proporcionar un menor desfase y fluctuación en un dominio controlado; depende de las NIC, los conmutadores, los controladores y las fuentes de reloj, por lo que el dominio de fallas y la configuración son mayores. Para el ordenamiento de eventos, los relojes lógicos o las secuencias de bases de datos suelen ser más directos que buscar un tiempo físico más estricto. Para la duración en un solo host, el tiempo monotónico es la herramienta adecuada para ambos casos.

Modos de falla, límites y contraejemplos

• Tratar “NTP sincronizado” como prueba de que las marcas de tiempo del negocio son precisas, ignorando el desfase, el stratum y los cambios de fuente.
• Utilizar CLOCK_REALTIME para plazos límite; los cambios manuales o la corrección del reloj pueden hacer que un tiempo de espera venza antes o después.
• Prometer precisión de microsegundos con PTP en un host en la nube sin sellado de tiempo por hardware; la capacidad de la red es una condición previa.
• Inferir la causalidad entre nodos a partir de marcas de tiempo de pared. El retraso de la red puede producir empates u observaciones invertidas; utilice datos de secuencia, versión o reloj lógico.
• Continuar emitiendo firmas o registros de auditoría aparentemente precisos tras perder la sincronización; registre la fuente de tiempo, la antigüedad de la sincronización y la incertidumbre, y luego etiquete o rechace las operaciones de alto riesgo que superen un umbral.

Lista de verificación de pruebas y verificación

Verifique tres capas: pruebe la semántica de tiempo real y monotónica en cada nodo; recopile el desfase de NTP/PTP, la fluctuación, el error de frecuencia y la antigüedad de la sincronización; luego inyecte retraso, pérdida de paquetes, cambios en fuentes ascendentes y reinicios. Establezca la aceptación como “bajo la red y el hardware especificados, el 99.9% de las ventanas se mantienen por debajo de un desfase X”, y pruebe la retención (holdover) y la recuperación por separado. Una sola comparación de date no constituye una validación.

Preguntas de seguimiento

¿Cómo se deben ordenar los eventos entre nodos?

Utilice el tiempo físico para visualización y campos de auditoría, pero otorgue la causalidad a versiones monotónicas, números de secuencia de mensajes, orden de confirmación (commit) de base de datos o relojes lógicos. Si se requiere una línea de tiempo orientada a humanos, exponga el intervalo de incertidumbre y aplique un criterio de desempate estable dentro de los intervalos superpuestos.

¿Puede PTP reemplazar completamente a NTP?

No existe un reemplazo universal. PTP se adapta a un dominio controlado con un presupuesto de precisión explícito; NTP sigue cubriendo redes de gestión, enlaces de área amplia y hosts sin hardware PTP. Un diseño común utiliza PTP para un dominio crítico y ofrece NTP desde servicios dentro de ese dominio a otros hosts.

¿Debe detenerse un servicio cuando desaparece su fuente de tiempo?

Clasifique el riesgo de negocio. Las cachés o métricas ordinarias pueden continuar dentro de una retención (holdover) acotada; las firmas, certificados o emparejamientos financieros deben rechazar o escalar cuando la incertidumbre supere un umbral. Cada degradación necesita una alerta, una etiqueta de datos y un registro de calibración tras la recuperación.