Salto del reloj del sistema (step de NTP) Wall-clock jump (NTP step)
ID de la causa so-timejump · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura)
Si el reloj del servidor se adelanta o se atrasa varios segundos de golpe, los temporizadores que dependen del reloj del sistema se disparan todos a la vez o se detienen.
Por qué La sincronización horaria corrige el reloj con un salto grande de una sola vez → Efecto Los temporizadores se disparan en tropel o se detienen, y los timeouts se evalúan mal → En pantalla Buffs y cooldowns que fallan, desconexiones simultáneas, cámara rápida
Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de servidores (Equipo de infraestructura)
Tareas (Equipo de desarrollo)
Calcular el tiempo transcurrido, los timeouts y los cooldowns con un reloj monotónico (monotonic clock), que no salta ni retrocede, usar el reloj de pared (wall clock) solo para mostrar y registrar.
Tareas (Equipo de infraestructura)
Ajustar el reloj poco a poco (makestep de chrony solo justo después de arrancar), monitorear el estado de la sincronización horaria (desfase del reloj).
Cifras de referencia
ntpd corrige el reloj de una sola vez si la diferencia supera 0.128 segundos; si es menor, lo ajusta poco a poco, a un ritmo que tarda algo más de 30 minutos en eliminar 1 segundo de diferencia. chrony, muy usado hoy, con la configuración recomendada (makestep) solo corrige de golpe unas pocas veces justo después de arrancar, y después ajusta poco a poco. El reloj también salta cuando una máquina virtual se detiene un momento y se reanuda.
En el gráfico
Picos aleatorios · Temporizadores disparados y desconexiones, registro de ajustes del reloj
Dónde mirar
Registros de ajustes grandes de una sola vez en los logs del servicio de sincronización horaria, cruzados con la hora del problema. chrony deja constancia en syslog cuando el ajuste supera el valor de logchange (1 segundo por defecto)
Se confirma si
Hay un registro de ajuste del reloj a la hora de los fallos de buffs y cooldowns, las desconexiones simultáneas o la cámara rápida, y el tamaño del ajuste se parece a la magnitud del problema
Se descarta si
Si no hay registros de ajuste del reloj, no es esta causa. En máquinas virtuales, revisar también si se detuvo y se reanudó (“Mantenimiento del host en la nube y migración en vivo”)
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
Fuentes
ntpd - Network Time Protocol (NTP) daemonNetwork Time Foundation Si la diferencia supera el umbral de step de 128 ms, se corrige de una vez; si es menor, poco a poco, a 0.5 ms por segundo, así que corregir 1 segundo lleva 2,000 segundos (unos 33 minutos)
chrony – Frequently Asked Questionschrony Se recomienda permitir el step solo unas pocas veces justo después de arrancar, como makestep 1 3; una máquina virtual que se detuvo y se reanudó puede despertar con la hora desfasada
clock_gettime(2) — Linux manual pageLinux man-pages CLOCK_MONOTONIC no se ve afectado por los saltos discontinuos del reloj del sistema y no retrocede
chrony.conf(5)chrony logchange: si el reloj se ajusta más que este valor (1 segundo por defecto), se registra en syslog