Entrevista de Linux: ¿Cuándo se debe usar un reloj monotónico en lugar del tiempo de reloj de pared (wall-clock time)?

El problema y su ámbito de aplicación

Un servicio de Linux lee CLOCK_REALTIME cuando inicia una solicitud y aplica un timeout de dos segundos mediante “tiempo actual menos tiempo de inicio”. La misma fuente registra marcas de tiempo para auditoría, programa una tarea diaria a las 09:00 hora local y ordena eventos provenientes de varios servicios. Tras una corrección de NTP o un cambio manual de reloj, el tiempo de pared (wall time) puede dar un salto hacia adelante o hacia atrás. Algunas solicitudes expiran de inmediato; otras esperan mucho más de dos segundos.

Elija un reloj o mecanismo de ordenamiento para el tiempo transcurrido local y los timeouts, un lease que deba expirar mientras la máquina está suspendida, una programación de calendario humano, un tiempo de auditoría duradero y el ordenamiento causal entre máquinas. Aborde el reinicio de procesos, la serialización, el sesgo de reloj (clock skew) y un plan de verificación.

El timeout de dos segundos, el comportamiento ante suspensión y la programación son supuestos de entrevista. Los principales relojes de Linux son CLOCK_REALTIME, CLOCK_MONOTONIC y CLOCK_BOOTTIME; el runtime de un lenguaje puede envolverlos. La categoría es general porque la habilidad fundamental reside en la semántica del tiempo en el sistema operativo y el razonamiento sobre confiabilidad, más que en un framework de aplicación específico.

Un recurso de entrevistas de diseño de sistemas actualizado en 2026 aborda los relojes de pared, los relojes monotónicos, las correcciones de reloj y las fallas por sesgo como un solo tema de práctica. La justificación de POSIX.1-2024, las páginas man de Linux y la documentación de Go proporcionan límites de API verificables de forma independiente. Estas fuentes establecen su relevancia actual y su valor duradero de preparación; no establecen un enunciado ni una frecuencia de entrevistas específicos de una empresa.

Qué evalúa el entrevistador

Primero, ¿puede el candidato preguntarse qué interrogante debe responder un valor de tiempo? El tiempo de pared responde “¿qué instante civil o UTC es?” y se adapta a auditorías, validez de certificados y programaciones de calendario. El tiempo monotónico responde “¿cuánto tiempo transcurrió en este runtime?” y se adapta a duraciones, backoff y timeouts. Un nombre de API o la precisión en nanosegundos no reemplaza a la semántica.

Segundo, ¿sabe el candidato que monotónico no significa perfectamente uniforme, globalmente consistente ni en avance perpetuo? En Linux, CLOCK_MONOTONIC no sufre saltos discontinuos al ajustar la hora del sistema y no retrocede, pero los ajustes graduales de NTP afectan su frecuencia y no contabiliza la suspensión del sistema. Lecturas consecutivas pueden incluso devolver el mismo valor.

Tercero, ¿puede el candidato distinguir entre CLOCK_MONOTONIC, CLOCK_BOOTTIME, CLOCK_MONOTONIC_RAW y el tiempo de CPU? BOOTTIME es monotónico e incluye la suspensión. MONOTONIC_RAW evita el ajuste gradual de NTP y es útil para mediciones de reloj de bajo nivel, pero no es la respuesta predeterminada para timeouts en aplicaciones. Los relojes de CPU de proceso y de hilo cuentan la ejecución en una CPU, no el tiempo pasado en espera.

Cuarto, ¿evitará el candidato persistir o transmitir una lectura monotónica local como si fuera una marca de tiempo universal? Su origen no tiene significado de calendario y no representa una línea de tiempo duradera a través de reinicios. Las marcas de tiempo físicas por sí solas no pueden demostrar el orden entre máquinas. Una secuencia de negocio, una posición de commit en base de datos, un registro de consenso, un reloj de Lamport o un reloj lógico híbrido deben garantizar la corrección cuando el requisito lo exija.

Por último, ¿puede el candidato inyectar fallas de reloj reales? Esperar dos segundos una sola vez no cubre saltos de reloj de pared, ajustes graduales (slewing), suspensión, reinicio ni sesgo remoto.

Preguntas para aclarar antes de responder

• ¿Dos segundos significan tiempo de ejecución activo o tiempo transcurrido real? Un timeout de solicitud mientras el proceso se ejecuta normalmente utiliza CLOCK_MONOTONIC. Un lease local que debe haber expirado tras un minuto de suspensión debe considerar CLOCK_BOOTTIME.
• ¿El deadline debe sobrevivir al reinicio del proceso? Un deadline monotónico en memoria pertenece a una sola instancia en ejecución. Persista una expiración autoritativa en tiempo de pared o un estado de negocio, y luego establezca un presupuesto local acotado tras el inicio.
• ¿Qué zona horaria define “diariamente a las 09:00” y qué ocurre en un salto o repetición por horario de verano (DST)? Una tarea de calendario necesita una zona IANA y una política para instantes locales inexistentes o duplicados. El tiempo monotónico no puede expresar esa regla.
• ¿Qué debe probar un registro de auditoría? Un instante UTC legible facilita la búsqueda y el cumplimiento, pero los empates, el retroceso del reloj y el sesgo entre múltiples hosts también requieren un ID estable, una secuencia de commit o un campo causal.
• ¿El ordenamiento entre servicios sirve para visualización, deduplicación, causalidad o un orden total estricto? La visualización puede tolerar sesgos. Un libro mayor o una máquina de estados replicada normalmente necesita una autoridad de commit o un registro de consenso en lugar de “gana la marca de tiempo mayor”.
• ¿Cómo maneja la plataforma de destino la suspensión y la migración de VM? Linux define la semántica de sus relojes, pero el runtime del lenguaje real, el host, la capa de virtualización y la resolución aún requieren verificación específica para cada versión.
• ¿La sincronización aplica saltos (step) o ajustes graduales (slew) al reloj? Un salto en el reloj de pared rompe directamente la resta de duraciones. El ajuste gradual deja el tiempo monotónico sin decrementos, pero modifica levemente su frecuencia respecto al contador de hardware sin procesar.

Estructura de respuesta en 30 segundos

“Elijo el reloj en función de la pregunta que se deba responder. Las marcas de tiempo de auditoría y las programaciones diarias a las 09:00 requieren tiempo de pared duradero. Una duración de dos segundos o un timeout dentro de un proceso usa un reloj monotónico para que un salto en el reloj de pared no lo haga expirar antes o después de tiempo. Si la suspensión debe consumir un lease, Linux proporciona CLOCK_BOOTTIME. No serializo lecturas monotónicas ni las comparo entre reinicios o máquinas. El tiempo de pared entre servicios es observacional; una versión de negocio, un log de commits o un reloj lógico aportan la corrección. Inyectaría saltos hacia adelante y hacia atrás en el reloj de pared, y luego probaría ajustes graduales, suspensión, reinicio y sesgo entre hosts contra un invariante separado para cada caso de uso.”

Análisis detallado paso a paso

Paso 1: Dividir un valor de tiempo en cinco requisitos

Construya una tabla de decisión en lugar de asignar una única fuente a todo el sistema:

Un registro puede contener dos dimensiones de tiempo. Por ejemplo, un log de solicitud almacena un observed_at en UTC para consultas, mientras que el proceso calcula duration_ms a partir de una lectura monotónica de inicio. Los campos responden a preguntas distintas y no se sustituyen entre sí.

Paso 2: Explicar por qué el tiempo de pared rompe la resta de duraciones

Supongamos que el código evalúa elapsed = realtime_now - realtime_start. Si el tiempo de pared se adelanta 90 segundos tras iniciarse la solicitud, la siguiente comprobación declarará falsamente un timeout. Si retrocede 90 segundos, elapsed puede volverse negativo y la solicitud podría esperar hasta que el tiempo de pared lo alcance. NTP también puede corregir la hora gradualmente modificando la frecuencia del reloj. El tiempo de pared debe alinearse con el tiempo civil externo, por lo que una aplicación no puede asumir lecturas consecutivas estrictamente crecientes.

Tome las lecturas de inicio y actual del mismo reloj monotónico, o use una API de temporizador/deadline explícitamente basada en él. Nunca reste una lectura de realtime de una monotónica; sus orígenes difieren. No elija MONOTONIC_RAW simplemente porque 'raw' suene más preciso. Los timeouts de aplicaciones normalmente se benefician de un reloj no decreciente cuyos segundos se mantienen disciplinados respecto a los segundos reales, que es lo que proporciona el reloj monotónico estándar de POSIX/Linux.

Paso 3: Decidir si la suspensión consume el presupuesto

En Linux, CLOCK_MONOTONIC deja de acumular tiempo mientras el sistema está suspendido. Si una laptop entra en suspensión durante un minuto, un temporizador local MONOTONIC de 30 segundos aún puede tener tiempo restante tras reanudarse. Esto puede ajustarse a tareas definidas en tiempo ejecutable, pero no a una sesión o lease de seguridad que debe expirar mientras la máquina duerme.

CLOCK_BOOTTIME incluye la suspensión y se ajusta a esta última regla. Despertar una máquina suspendida para realizar un trabajo requiere además la capacidad de alarma y los permisos adecuados; elegir BOOTTIME no la despierta por sí solo. Un lease que abarque un reinicio no puede persistir únicamente un valor numérico de BOOTTIME, ya que un nuevo arranque no ofrece una continuación portable del origen anterior.

Paso 4: Gestionar por separado las fechas límite de calendario y la persistencia

“Diariamente a las 09:00” es una regla de calendario. Requiere tiempo de pared, una zona horaria nombrada y una política de DST. Las 09:00 de una fecha pueden mapearse a un desplazamiento UTC distinto tras un cambio de normativa; algunas horas locales se repiten o no existen. Almacene la expresión de calendario y la zona en lugar de convertirla una sola vez al iniciar en una duración monotónica que nunca se recalcula. Una vez que se dispara una ocurrencia, el tiempo monotónico puede gobernar el timeout de ejecución de esa corrida.

Los datos de auditoría deben almacenar un instante UTC normalizado, la zona u offset original cuando el negocio lo requiera, un ID de registro y un orden de commit autoritativo. El tiempo de pared es legible por humanos, pero no es único ni estrictamente creciente. Marcas de tiempo iguales o menores durante un retroceso por NTP no deben corromper una clave primaria, un cursor o el orden de un saldo.

Paso 5: Acotar la propagación entre procesos y entre máquinas

Una lectura monotónica absoluta solo tiene sentido en su entorno de ejecución definido. La documentación oficial de Go descarta explícitamente la lectura monotónica durante la serialización. Un protocolo no puede enviar monotonic_deadline=8374921 a otro host y solicitarle que compare directamente; ese host puede tener otro origen, ciclo de arranque o contrato de API.

Una RPC puede propagar un presupuesto restante acotado o un deadline UTC, pero el compromiso debe ser explícito. Cada salto consume el presupuesto mediante un reloj monotónico local y deja margen para tránsito, encolamiento y sesgo. Un lease de alto riesgo no puede confiar únicamente en la hora del cliente. La autoridad del servidor, una época de lease y un token de fencing deciden si las escrituras siguen siendo válidas.

El ordenamiento de eventos sigue el mismo enfoque basado en requisitos. Una interfaz de logs puede mostrar tiempo de pared y señalar posibles sesgos. La causalidad puede utilizar trace parents, secuencias de mensajes o relojes lógicos. Un orden estricto de máquina de estados usa una posición de commit en base de datos o un registro de consenso. Ordenar todos los eventos por created_at proporciona un orden de observación, no una prueba de precedencia real.

Paso 6: Transformar las pruebas en invariantes de reloj

Utilice un reloj inyectable o un espacio de nombres de tiempo / reloj virtual de la plataforma en un entorno de pruebas para cubrir:

1. Adelantar el tiempo de pared 90 segundos después de 500 ms; el timeout monotónico de dos segundos no debe dispararse de inmediato.
2. Retroceder el tiempo de pared 90 segundos; el timeout se dispara tras aproximadamente dos segundos transcurridos, mientras que los logs UTC pueden retroceder sin colisión de IDs.
3. Simular corrección gradual, verificar que no haya duraciones negativas y registrar el error de medición permitido.
4. Suspender por más tiempo que un lease. Una tarea MONOTONIC conserva su presupuesto definido; un lease BOOTTIME ha expirado.
5. Reiniciar el proceso. No se restaura ninguna lectura monotónica antigua; el estado de expiración persistido se restablece según su contrato.
6. Asignar a dos nodos de prueba desfases de reloj opuestos. La máquina de estados sigue aplicando eventos por versión o posición de log, no por la magnitud del reloj de pared.
7. Simular un salto y una repetición por DST, verificando la política explícita para las 09:00 diarias.

Como mínimo, monitoree el recuento de duraciones negativas, errores de timeout, expiraciones tempranas y tardías, eventos de salto/ajuste gradual de reloj, sesgo de host, ejecuciones duplicadas por DST y escrituras rechazadas por colisiones de marcas de tiempo. El desfase de 90 segundos es un valor de inyección de fallas, no una afirmación sobre el sesgo en producción.

Respuesta de muestra de alta calidad

“Esta implementación asigna tres significados a un solo valor de CLOCK_REALTIME. El tiempo de pared debe aceptar modificaciones manuales y sincronización. Un salto hacia adelante hace que now - start supere repentinamente los dos segundos; un retroceso hace que la diferencia sea menor o negativa. Calcularía las duraciones y el backoff de las solicitudes dentro de un único dominio de tiempo monotónico, preferiblemente mediante una API de deadline vinculada a ese reloj.

Luego separaría los demás requisitos. Los registros de auditoría conservan el tiempo de pared en UTC más un ID de registro estable. La tarea diaria de las 09:00 conserva una zona IANA y una política explícita de DST. Si un lease local debe expirar durante la suspensión, se utiliza CLOCK_BOOTTIME de Linux; si solo cuenta el tiempo ejecutable, se utiliza CLOCK_MONOTONIC. Ni el tiempo de CPU ni MONOTONIC_RAW son sustitutos directos para el timeout ordinario de una solicitud.

No almacenaría una lectura monotónica en una base de datos, ni la enviaría a otro host, ni la restauraría tras un reinicio. Los logs entre servicios pueden incluir tiempo de pared con fines de observación, pero una versión, secuencia de mensajes, log de commits o reloj lógico es dueño del orden de negocio. Cada salto RPC consume un presupuesto acotado con su reloj monotónico local, mientras que un lease de seguridad recurre además a la autoridad del servidor y fencing.

Por último, inyectaría un salto de 90 segundos hacia adelante, un retroceso de 90 segundos y una corrección gradual; luego probaría suspensión, reinicio de proceso, dos nodos con sesgos opuestos y transiciones de DST. Superar la prueba implica: cero duraciones negativas, ausencia de timeouts inmediatos o retrasados 90 segundos por saltos de reloj de pared, el comportamiento de suspensión prometido y un orden de estados entre hosts que no se vea alterado por el sesgo físico.”

Errores comunes

• Mover cada marca de tiempo a un reloj monotónico → los valores monotónicos carecen de significado de calendario intercambiable y no pueden expresar las 09:00 diarias → elegir por separado para duraciones, calendarios, auditorías y ordenamiento.
• Seguir restando CLOCK_REALTIME para un timeout → un salto hacia adelante expira antes de tiempo y un retroceso expira tarde → calcular inicio, deadline y hora actual en un único dominio monotónico.
• Afirmar que el tiempo monotónico no se ve afectado en absoluto por NTP → Linux MONOTONIC evita saltos discontinuos pero acepta ajustes graduales de frecuencia → separar 'nunca retrocede' de 'perfectamente uniforme'.
• Asumir que CLOCK_MONOTONIC incluye la suspensión → Linux excluye el tiempo suspendido → definir primero la semántica de suspensión y usar BOOTTIME cuando deba contabilizarse.
• Tratar CLOCK_MONOTONIC_RAW como un valor predeterminado mejorado → eludir la disciplina del reloj puede empeorar la medición de segundos reales → usar tiempo monotónico estándar para timeouts de aplicaciones y evaluar raw para mediciones de bajo nivel.
• Serializar un deadline monotónico hacia otro host → el receptor no posee un origen compartido portable → propagar un presupuesto definido o deadline UTC, convertir localmente y acotar el riesgo de sesgo.
• Usar created_at como orden de negocio entre hosts → el sesgo y el retroceso pueden invertir eventos → asignar la corrección a versiones, posiciones de commit, logs de consenso o relojes lógicos.
• Probar un único cambio manual de reloj → ajustes graduales, suspensión, reinicio y DST quedan sin cobertura → usar una matriz de reloj inyectable y verificar invariantes independientes.

Preguntas de seguimiento y respuestas

¿La corrección gradual de NTP hace inexacto un intervalo de dos segundos con CLOCK_MONOTONIC?

Puede ajustar ligeramente la frecuencia del reloj, pero no genera el retroceso discontinuo de un salto en el reloj de pared. Los timeouts comunes normalmente requieren un reloj no decreciente y disciplinado por el sistema cuyos segundos se mantengan próximos a los segundos reales, por lo que dicho ajuste es adecuado. El código de sincronización de reloj, benchmarks de hardware o análisis de frecuencia pueden evaluar CLOCK_MONOTONIC_RAW y gestionar por separado la suspensión y la deriva.

Un lease debe sobrevivir a un reinicio y expirar mientras la máquina está fuera de línea durante un minuto. ¿Qué cambia?

No persista un valor MONOTONIC o BOOTTIME local absoluto. El servidor almacena un instante de expiración en tiempo de pared, una época de lease y un token de fencing, y el cliente revalida con esa autoridad tras reconectarse. Durante una corrida del proceso, el presupuesto restante otorgado puede convertirse en un deadline local BOOTTIME. Aunque un proceso antiguo crea erróneamente que su lease sigue activo, la capa de almacenamiento rechazará su token de fencing obsoleto.

Si ambos servicios usan NTP, ¿pueden las marcas de tiempo en milisegundos determinar el orden de los eventos?

No. La sincronización reduce la incertidumbre pero no demuestra causalidad entre dos lecturas físicas, y el retardo de red altera el orden de observación. Para visualización en logs, conserve ambos valores y exponga la incertidumbre. Para evitar que un estado antiguo sobrescriba a uno nuevo, utilice una versión por entidad, secuencia de mensajes, posición de commit en base de datos o reloj lógico. Un orden total estricto requiere un consenso o una ruta con secuenciador único.

¿Por qué no medir la latencia de solicitudes con el tiempo de CPU del proceso?

Una solicitud puede esperar en la red, disco, un bloqueo o un pool de conexiones. Esas esperas afectan la latencia percibida por el usuario sin consumir apenas CPU. El tiempo de CPU mide el costo computacional; un reloj de tiempo transcurrido mide la latencia de extremo a extremo y el timeout. Ambos pueden registrarse, pero responden a preguntas diferentes.

¿Cómo debe comportarse la tarea diaria de las 09:00 en una transición de horario de verano?

Defina primero la regla de negocio. Para una hora local inexistente, omítala o muévala al siguiente instante válido. Para una hora repetida, ejecútela una sola vez o una vez por cada offset. Almacene la zona IANA y una clave de deduplicación en lugar de solo el desplazamiento UTC actual. Una vez seleccionada la siguiente ocurrencia en el calendario, la espera local y el timeout de ejecución pueden seguir utilizando tiempo monotónico.