KomuraSoft LLC
Contáctenos
Menú

Sincronización horaria de Windows (w32time) y los sistemas de negocio — resolver desde la raíz por qué «las marcas de tiempo de los registros no coinciden»

· Actualizado el: · · w32time, NTP, Sincronización horaria, Windows, Registros, Investigación de fallos, Integración con dispositivos, Active Directory

«El equipo se detuvo por un fallo. Al cotejar el registro del equipo con el registro de la aplicación del PC, encontramos una diferencia de 40 segundos entre ambos, y no pudimos determinar con certeza si el error del equipo o el corte de comunicación de la aplicación había ocurrido primero» — es una situación con la que nos hemos topado una y otra vez al investigar fallos en sistemas que integran dispositivos. Cámaras de red, PLC, equipos de inspección y PC con Windows: cada uno registra sus eventos con su propio reloj, y en realidad nadie había garantizado que esos relojes coincidieran entre sí.

En condiciones normales, casi nadie se percata de esta desviación. El problema surge invariablemente durante la investigación de un fallo, es decir, cuando el «orden cronológico de los eventos» se necesita como evidencia. Y en cuanto se empieza a investigar, van saliendo hechos uno tras otro: «el PC del grupo de trabajo solo se sincronizaba una vez por semana», «la máquina virtual oscilaba porque recibía la hora tanto del host como de NTP», «en realidad nadie había ajustado el reloj del dispositivo».

Este artículo va dirigido a desarrolladores y responsables de sistemas de información que hayan sufrido dificultades al cotejar registros entre dispositivos y PC, o entre servidores y terminales. Repasamos, con el respaldo de fuentes primarias de Microsoft, el funcionamiento del servicio de sincronización horaria de Windows (w32time), la práctica de diagnóstico con el comando w32tm, las expectativas realistas de precisión y, finalmente, cómo diseñar el lado del sistema de negocio partiendo de la premisa de que «la hora se desvía y puede retroceder».

1. Conclusión principal

  • La hora de Windows la gestiona el servicio Windows Time (w32time). No es una implementación estricta de NTP, pero sí un cliente/servidor NTP que ajusta el reloj mediante los algoritmos definidos en la especificación NTP, y se comunica por el puerto UDP 123.1
  • En un entorno de dominio existe una jerarquía horaria fija. Los miembros se sincronizan con el controlador de dominio (DC), el DC con el DC del dominio padre, y en la cúspide está el emulador de PDC del dominio raíz del bosque. Si ese nodo superior no está sincronizado con una fuente horaria externa precisa, todo el dominio queda equivocado por igual.1
  • Los equipos en grupo de trabajo (fuera de dominio) se sincronizan por defecto con time.windows.com con muy poca frecuencia. El valor predeterminado del registro SpecialPollInterval es de 604 800 segundos (una semana) en una configuración independiente. Una desviación de decenas de segundos ocurre «tal como está diseñado».23
  • Para el diagnóstico basta con el conjunto de comandos w32tm. w32tm /query /status muestra el estado de sincronización y el origen; /stripchart mide la diferencia horaria real frente a otro equipo; /config /manualpeerlist indica el origen de sincronización; y /resync fuerza una resincronización inmediata.2
  • w32time corrige las desviaciones pequeñas ajustando gradualmente la velocidad del reloj (slew) y las desviaciones grandes reescribiendo el reloj de forma directa (step). Esto significa que el reloj del sistema puede saltar tanto hacia delante como hacia atrás. También es importante saber que, si la desviación supera el límite (MaxPosPhaseCorrection/MaxNegPhaseCorrection), no se corrige: solo se registra en el visor de eventos.12
  • El objetivo de diseño de la configuración predeterminada era, históricamente, cumplir apenas el margen de 5 minutos que exige Kerberos. A partir de Windows Server 2016 / Windows 10 1607 la precisión mejoró considerablemente, y si se cumplen condiciones como disponer de una fuente Stratum 1 precisa, una latencia de red adecuada y un número limitado de saltos, entran dentro del ámbito de soporte precisiones de 1 segundo, 50 ms e incluso 1 ms.4
  • Un invitado de Hyper-V dispone de dos proveedores de hora: el host y NTP. Desde Windows Server 2016, el invitado elige el más adecuado de forma mejorada, pero en un invitado unido a un dominio con Windows Server 2012 R2 o anterior se recomienda deshabilitar el proveedor de sincronización horaria de Hyper-V.3
  • Del lado de la aplicación, el diseño debe partir de que «la hora se desvía y puede retroceder». La hora de los registros se guarda en UTC, y el tiempo transcurrido se mide con Stopwatch, que aumenta de forma monótona con independencia del reloj del sistema. Esta separación de usos es la base de todo lo demás.56

2. Cómo funciona w32time — el comportamiento difiere por completo entre dominio y grupo de trabajo

El servicio Windows Time (W32Time) es el componente estándar de sincronización horaria de Windows. Obtiene muestras de hora de fuentes en la red mediante NTP (y, para dominios, la variante segura MS-SNTP), selecciona la mejor muestra con los algoritmos de filtrado y selección de reloj de NTP, y ajusta el reloj local en consecuencia.1

Lo que conviene tener claro es que la forma en que se determina el origen de sincronización cambia radicalmente según la configuración.

En un entorno de dominio (Type=NT5DS), el bosque de AD DS tiene predefinida una jerarquía horaria. Los PC y servidores miembros se sincronizan con el DC de su propio dominio, el DC se sincroniza con el DC del dominio padre, y en la cúspide de la jerarquía está el emulador de PDC del dominio raíz del bosque (o un DC configurado como fuente horaria de confianza). Los paquetes NTP van firmados con la clave de sesión de Kerberos, de modo que solo se acepta una hora autenticada.1 Por eso, dentro de un mismo dominio, los PC suelen quedar razonablemente alineados entre sí. El problema está en la cúspide: si el emulador de PDC no está sincronizado con una fuente horaria externa precisa (un reloj GPS o un servidor NTP de confianza), «todos quedarán alineados, pero en una hora equivocada». Esta desviación sale a la luz precisamente en el momento en que se cotejan los registros con un sistema externo o con la nube.

Esta parte la configura el administradorFuente horaria externa precisaReloj GPS / servidor NTP de confianzaEmulador de PDC deldominio raíz del bosqueDC del dominio hijoOtro DC del mismo dominioServidor miembro / PCServidor miembro / PCServidor miembro / PC

Figura 1: jerarquía horaria de dominio — las flechas indican la dirección en que se distribuye la hora

Al ver este árbol de un vistazo, queda claro que si la raíz está equivocada, todos se equivocan por igual. Y como todos quedan alineados en el error, mientras solo se comparen registros internos nadie lo nota. El problema solo se descubre el día en que se cotejan con algo externo. Por eso lo primero que hay que revisar es la configuración de ese nodo superior.

En un entorno de grupo de trabajo (Type=NTP), el origen de sincronización predeterminado es time.windows.com,0x1. 0x1 (SpecialInterval) es el indicador que hace que el intervalo de sondeo se determine mediante el valor de registro SpecialPollInterval, cuyo valor predeterminado en una configuración independiente es de 604 800 segundos, es decir, una semana.2 Incluso en un cliente Windows 10 la frecuencia ronda una vez al día, y en la generación de Windows Server 2012 R2 el valor predeterminado era de una vez por semana.3 Como el reloj interno del PC (el oscilador de cuarzo) suele derivar del orden de segundos por día debido a factores como la temperatura, con una sincronización semanal es normal que aparezcan desviaciones de decenas de segundos. La «desviación de 40 segundos» mencionada al principio suele tener este origen.

Otro aspecto importante en la práctica es el comportamiento de la disciplina de reloj (clock discipline). Mientras la desviación es pequeña, w32time la corrige gradualmente ajustando la velocidad del reloj (slew); cuando supera MaxAllowedPhaseOffset, ajusta el reloj de forma directa (step).12 Además, si la desviación supera MaxPosPhaseCorrection/MaxNegPhaseCorrection (54 000 segundos, es decir, 15 horas, por defecto en una configuración independiente), no se corrige: solo se registra el evento.2 Cuando «se supone que está sincronizado pero la hora no se corrige», a veces el motivo es haber topado con este límite. Y como la corrección por step también puede aplicarse en sentido negativo, es decir, el reloj del sistema de Windows puede saltar hacia atrás, este hecho enlaza con el diseño de la aplicación que se trata más adelante.

3. La práctica con el comando w32tm — verificar el estado, medir la diferencia real y cambiar el origen de sincronización

En la práctica, para investigar cuestiones de hora basta con cinco comandos. Todos se ejecutan en un símbolo del sistema con privilegios de administrador.2

Lo primero es comprobar el estado actual.

w32tm /query /status

うるう秒インジケーター: 0(警告なし)
階層: 4 (二次参照 - (S)NTP で同期)
精度: -23 (ティックごとに 119.209ns)
ルート遅延: 0.0312500s
ルート分散: 7.7756348s
参照 ID: 0xC0A80A14 (ソース IP:  192.168.10.20)
最終正常同期時刻: 2026/07/22 8:14:02
ソース: dc01.example.local
ポーリング間隔: 10 (1024s)

Hay tres puntos que conviene revisar. Primero, si «Source» (la fuente) corresponde al equipo esperado (si aparece Local CMOS Clock o Free-running System Clock, en la práctica no hay sincronización). Segundo, si «Last Successful Sync Time» (última sincronización correcta) es reciente (si fue hace varios días, la sincronización no está funcionando). Tercero, si el «Stratum» (nivel jerárquico) es razonable (cuántos saltos hay desde una fuente horaria precisa; w32time solo acepta hasta Stratum 15).7 Si solo necesita conocer el origen de sincronización, use w32tm /query /source; para el estado de varios orígenes, w32tm /query /peers; y para los valores de configuración junto con su procedencia (directiva o local), w32tm /query /configuration.

La salida anterior corresponde a un Windows con configuración regional japonesa. En un entorno en inglés, los nombres de los campos cambian, así que aquí tiene la correspondencia entre ambos. Puede usarla al comunicarse con personal de sedes en el extranjero o al buscar información en inglés. Tenga en cuenta que los nombres mostrados varían según la configuración regional, así que no conviene escribir scripts que analicen esta salida de forma mecánica.

Texto mostrado en japonés Texto mostrado en inglés
うるう秒インジケーター Leap Indicator
階層 Stratum
精度 Precision
ルート遅延 Root Delay
ルート分散 Root Dispersion
参照 ID ReferenceId
最終正常同期時刻 Last Successful Sync Time
ソース Source
ポーリング間隔 Poll Interval

A continuación, la medición real de la diferencia horaria frente a otro equipo. Se usa en la investigación de fallos para expresar en cifras cuánta desviación hay ahora mismo entre el servidor y este PC.

w32tm /stripchart /computer:192.168.10.20 /samples:5 /dataonly

192.168.10.20 [192.168.10.20:123] の追跡中。
現在の時刻は 2026/07/24 9:41:03 です。
09:41:03, +28.1246875s
09:41:05, +28.1250120s
09:41:07, +28.1248533s
09:41:09, +28.1251008s
09:41:11, +28.1249517s

En este ejemplo se puede concluir de inmediato que «este PC va unos 28 segundos por detrás del otro equipo». Como /stripchart es una medición solo de visualización y no modifica el reloj local, se puede usar sin riesgo incluso en un PC de un equipo que esté en funcionamiento. Antes de cotejar los registros, lo primero que hacemos en nuestra empresa al investigar un fallo es ejecutarlo contra todas las máquinas implicadas y elaborar una tabla de desviaciones antes de empezar el cotejo.

Para indicar explícitamente el origen de sincronización se usa /config. La forma habitual de especificar un servidor NTP interno (o un DC) es la siguiente.

w32tm /config /manualpeerlist:"ntp1.example.local,0x8 ntp2.example.local,0x8" /syncfromflags:manual /update
w32tm /resync

0x8 es el indicador que sincroniza en modo cliente; si se combina con 0x1 (SpecialInterval), es decir ,0x9, el sondeo sigue el intervalo definido por SpecialPollInterval. Con 0x1 en solitario se pierde el indicador de modo cliente, así que si va a especificarlo, use ,0x8 o ,0x9. Cuando solo se dispone de dos servidores, se recomienda añadir 0x2 (UseAsFallbackOnly) a uno de ellos para dejar clara la prioridad (Microsoft indica que, si se pueden preparar tres o más, es mejor hacerlo así).2 Para dejar de usar la indicación manual y volver a la jerarquía de dominio, ejecute w32tm /config /syncfromflags:domhier /update y reinicie el servicio. w32tm /resync descarta las estadísticas de error acumuladas y fuerza una resincronización inmediata; se usa para confirmar que un cambio de configuración se ha aplicado.2

El valor numérico que se añade tras el nombre del servidor es el indicador NtpServer. Como está disperso en la documentación y es fácil usarlo mal, lo resumimos en una sola tabla.2

Indicador Nombre Significado
0x1 SpecialInterval Determina el intervalo de sondeo mediante el valor de registro SpecialPollInterval
0x2 UseAsFallbackOnly Se usa como respaldo solo cuando no hay disponible otra fuente horaria
0x8 Client Se sincroniza con este equipo en modo cliente
0x9 Client + SpecialInterval Combinación de 0x8 y 0x1. La opción habitual cuando se quiere fijar el intervalo manualmente

No especifique 0x1 en solitario. Al no activarse el indicador de modo cliente, queda una configuración que solo fija el intervalo pero no sincroniza. Si quiere fijar el intervalo, use 0x9.

Acortar el intervalo de sondeo en PC de grupo de trabajo

El «acortamiento de SpecialPollInterval» que se menciona en la tabla de decisión del capítulo 7 se realiza cambiando el valor de registro y reiniciando el servicio. A continuación se muestra el procedimiento para pasar del valor predeterminado de 604 800 segundos (una semana) a 3600 segundos (una hora).2

rem (1) Fijar el intervalo de sondeo en 3600 segundos (el valor de REG_DWORD se indica en decimal)
reg add "HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient" /v SpecialPollInterval /t REG_DWORD /d 3600 /f

rem (2) SpecialPollInterval solo surte efecto en fuentes horarias con un indicador que incluya 0x1. Se indica con 0x9
w32tm /config /manualpeerlist:"ntp1.example.local,0x9 ntp2.example.local,0x9" /syncfromflags:manual /update

rem (3) Reiniciar el servicio para aplicar el cambio y sincronizar de inmediato
net stop w32time && net start w32time
w32tm /resync

rem (4) Comprobar el resultado aplicado y la procedencia de cada valor (directiva o local)
w32tm /query /configuration
w32tm /query /status

Si se omite el paso (2), aunque se cambie solo el registro el intervalo no varía, porque SpecialPollInterval solo se aplica a fuentes horarias que llevan el indicador 0x1. Además, en entornos donde la configuración horaria se distribuye por directiva de grupo, un cambio local del registro se sobrescribirá en la siguiente aplicación de la directiva. Compruebe la procedencia de cada valor en la salida de w32tm /query /configuration, y si está gestionado por directiva, configúrelo en «Configuración del equipo» > «Plantillas administrativas» > «Sistema» > «Windows Time Service» > «Time Providers» > «Configurar el cliente NTP de Windows».

Cabe señalar que indicar un NTP externo mediante /manualpeerlist es algo distinto de la hora autenticada del dominio: al no estar autenticada, en principio no debe usarse en los miembros del dominio, sino en el nodo superior (el emulador de PDC) o en equipos que no pertenecen a un dominio.1

4. La precisión — hasta dónde llega la configuración predeterminada y los requisitos para 1 ms

A la pregunta de «¿hasta qué punto se ajusta realmente la sincronización NTP de Windows?» la respuesta varía según la época.

En Windows Server 2012 R2 / Windows 8.1 y versiones anteriores, el objetivo de diseño de w32time era ofrecer la precisión necesaria para cumplir el requisito de autenticación Kerberos (5 minutos por defecto) y una hora «aproximadamente correcta» dentro del mismo bosque; se indica explícitamente que cualquier requisito de precisión más estricto queda fuera del alcance de diseño y sin soporte.4 Dicho de otro modo, es un mundo en el que «si coincide al segundo, funciona tal como está diseñado».

A partir de Windows Server 2016 / Windows 10 1607, los algoritmos mejoraron y la frecuencia de actualización del reloj también se elevó de forma considerable por defecto (por ejemplo, un servidor pasó de ajustar el reloj una vez por hora a hacerlo cada segundo).3 Como resultado, si se cumplen ciertas condiciones, se definen precisiones de 1 segundo, 50 ms y 1 ms como límites de soporte. Las principales condiciones para 1 ms son las siguientes; dicho de otro modo, no debe esperarse 1 ms en un entorno que no las reúna todas.4

  • Una jerarquía NTP cuya cúspide sea una fuente Stratum 1 precisa y estable (por ejemplo, un reloj GPS), con todos los equipos Windows del recorrido configurados para alta precisión
  • Una latencia de red inferior a 0,1 ms con la fuente horaria, y una distancia de hasta Stratum 5 y 4 saltos desde ella
  • Un uso de CPU (promedio diario) igual o inferior al 80 % en cada nivel de la jerarquía (incluido el host en entornos virtualizados)

Además, con fuentes horarias remotas en internet, como time.windows.com, se indica que no puede esperarse una precisión de 1 ms, debido a la asimetría de las rutas y a la congestión de la red.7 Como referencia práctica, es prudente pensar en tres niveles: «grupo de trabajo con configuración predeterminada = puede desviarse de segundos a decenas de segundos», «sincronización NTP interna bien configurada = de decenas de ms a menos de 1 segundo» y «fuente horaria dedicada con diseño específico = del orden de los ms». Si la integración con un dispositivo requiere determinar el orden de eventos con precisión de milisegundos, no conviene confiar en la sincronización horaria, sino orientar el diseño, como se explica más adelante, hacia medir con el reloj de un único equipo.

5. El tiempo en máquinas virtuales — la doble relación entre el servicio de integración de sincronización horaria de Hyper-V y NTP

La hora de una máquina virtual es un terreno más propenso a complicarse que el de una máquina física. La razón es sencilla: hay dos fuentes que le proporcionan la hora. Un Windows invitado de Hyper-V dispone tanto del servicio de integración de sincronización horaria de Hyper-V (el proveedor VMICTimeSync), que recibe la hora del host, como del cliente NTP habitual, y Windows elige el «mejor» de los dos atendiendo, en este orden, al nivel jerárquico (Stratum), el retardo raíz, la dispersión raíz y el desfase.7

Con Windows Server 2016 este mecanismo mejoró de forma considerable. La hora inicial al arrancar o restaurar una VM se volvió más precisa, y ahora se pasan a w32time muestras corregidas por el retardo de interrupción, lo que permite mantener una precisión de unos 10 µs respecto al host. El Stratum que el host reporta al invitado también pasó a ser un valor acorde a la realidad («Stratum del host + 1»), de modo que un invitado unido a un dominio con 2016 o posterior elige el reloj más preciso, en lugar de depender sin más del host.3

Por otro lado, cuando se ejecuta en un dominio un invitado de Windows Server 2012 R2 o anterior, el proveedor de sincronización horaria de Hyper-V puede perturbar la sincronización horaria del dominio, por lo que Microsoft recomienda deshabilitarlo.3

reg add HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider /v Enabled /t REG_DWORD /d 0 /f
net stop w32time && net start w32time

También hay una guía específica para las VM de Azure, y el punto clave es: «en una VM unida a un dominio (en especial un DC virtualizado), deshabilite TimeSync y dependa únicamente de la jerarquía de dominio; en una VM independiente que no pertenece a un dominio, deje la sincronización con el host tal como viene por defecto».3 Con hipervisores de terceros (como VMware) el planteamiento es el mismo: en un invitado unido a un dominio se recomienda desactivar la función de sincronización horaria del lado del host.3 Si observa el síntoma de que «NTP y la sincronización con el host se disputan el reloj por turnos, y la hora de los registros va y viene», sospeche de esta doble relación. También conviene añadir una precaución operativa: tras restaurar una VM desde un estado guardado o justo después de una migración en vivo, la corrección parte de un estado con una desviación horaria grande, así que no debe confiarse especialmente en la hora de los registros justo después de una restauración.

6. Diseño del lado del sistema de negocio — construir asumiendo que el reloj «se desvía y retrocede»

Hasta aquí hemos hablado del lado de la infraestructura, pero por bien que se configure la sincronización horaria, la desviación nunca llega a cero. Quien desarrolla software de integración con dispositivos debe diseñar los registros y la medición de tiempo partiendo de que la hora se desvía, e incluso puede retroceder.

El primer principio es registrar la marca de tiempo de los registros en UTC. Si se registra en hora local, la zona horaria, el horario de verano y las diferencias de configuración entre equipos entorpecen el cotejo (este tema se trata en detalle en «Fechas, horas y zonas horarias en aplicaciones de negocio»). El segundo principio es usar un reloj distinto según se trate de «cuándo ocurrió» o de «cuánto ha durado».

// [Trampa] Medir el tiempo transcurrido con el reloj del sistema
// Si w32time aplica una corrección por step, esta diferencia puede salir más larga, más corta o incluso negativa
var start = DateTime.UtcNow;
ExecuteInspection();
var elapsed = DateTime.UtcNow - start;   // usarlo para comprobar un tiempo de espera dispara falsos positivos

// [Práctica recomendada] Medir el tiempo transcurrido con Stopwatch (reloj de aumento monótono)
long t0 = Stopwatch.GetTimestamp();
ExecuteInspection();
TimeSpan elapsed2 = Stopwatch.GetElapsedTime(t0);   // .NET 7 en adelante. En versiones anteriores, Stopwatch.StartNew()

Stopwatch es una clase dedicada exclusivamente a medir el tiempo transcurrido contando ticks mediante un contador de rendimiento de alta resolución (equivalente a QueryPerformanceCounter), y no se ve afectada por las correcciones del reloj del sistema.5 DateTime.UtcNow, en cambio, es el propio reloj del sistema, y su resolución depende del temporizador del sistema (en general entre 0,5 y 15 ms).6 La comprobación de tiempos de espera, los intervalos de reintento, la medición de rendimiento, la medición del tiempo de respuesta de un dispositivo: todo procesamiento que trate con una «duración» debe apoyarse en Stopwatch.

En los registros conviene anotar ambos valores. Si se guarda un par formado por el reloj de pared (UTC) y el reloj monótono, más adelante se puede reconstruir el orden y el intervalo incluso en tramos que atraviesan una corrección por step de NTP.

public sealed class OpLog
{
    private static readonly long _baseTimestamp = Stopwatch.GetTimestamp();
    private static long _seq;

    public static void Write(string message)
    {
        long seq = Interlocked.Increment(ref _seq);
        // Hora UTC (cuándo ocurrió) + ms transcurridos de forma monótona desde el arranque (orden e intervalo) + número de secuencia (orden dentro de la misma hora)
        var line = $"{DateTime.UtcNow:yyyy-MM-dd'T'HH:mm:ss.fff'Z'}\t" +
                   $"{Stopwatch.GetElapsedTime(_baseTimestamp).TotalMilliseconds:F1}\t" +
                   $"{seq}\t{message}";
        // ... escribir en archivo o ETW
    }
}

Para cotejar registros entre varias máquinas y dispositivos conviene añadir dos elementos más. El primero es registrar periódicamente el desfase con el reloj del otro equipo. Los dispositivos con reloj propio, como una cámara o un PLC, a menudo permiten leer su hora a través del protocolo de comunicación, así que conviene anotar en el registro, al iniciar la aplicación y de forma periódica (por ejemplo, cada hora), la «diferencia entre la hora UTC del PC y la hora del dispositivo». Esto equivale a una versión para dispositivos de w32tm /stripchart, y permite, tras un fallo, hacer de forma mecánica un cotejo del tipo «durante este período, la hora del registro del dispositivo debe leerse aplicando una corrección de +12,3 segundos». El segundo es mantener alineado el sistema horario del registro de sucesos y ETW con el de los registros propios (véase «Introducción al registro de sucesos de Windows y ETW»). En el diseño de evidencias ante un fallo («Diseño para conservar registros y volcados al fallar una aplicación») o en la investigación de fallos de origen en la red, como un corte de comunicación con una cámara («Retransmisiones TCP que detienen la comunicación con cámaras industriales»), que el sistema horario esté o no alineado cambia el tiempo de investigación en un orden de magnitud.

En una LAN de fábrica sin conexión a internet, no se puede llegar a time.windows.com, así que la práctica habitual es levantar un servidor NTP local dentro de la LAN y alinear con él todos los equipos. Lo ideal sería disponer de un reloj GPS, pero incluso sin él, si se consigue que «aunque la hora absoluta esté algo desajustada, todos los equipos estén alineados con la misma referencia», el objetivo del cotejo de registros queda prácticamente cubierto. Para el servidor de referencia, conviene considerar también ajustar LocalClockDispersion, que determina la precisión declarada mientras no puede sincronizarse con el exterior.2

7. Tabla de decisión por entorno

Entorno Origen y frecuencia predeterminados Síntomas habituales Acción recomendada
PC/servidor unido a un dominio DC (NT5DS) → la cúspide es el emulador de PDC1 Todo el dominio queda desviado por igual respecto al exterior Configure una fuente horaria externa precisa en el emulador de PDC con /manualpeerlist. Deje los miembros con la configuración predeterminada
PC en grupo de trabajo time.windows.com, con una frecuencia baja de en torno a una vez por semana por defecto2 Una desviación de decenas de segundos se vuelve habitual Indique el NTP interno con /manualpeerlist (,0x9 = Client + SpecialInterval) y acorte SpecialPollInterval (por ejemplo, a 3600 segundos). Los pasos de los comandos están en el capítulo 3, «Acortar el intervalo de sondeo en PC de grupo de trabajo»
VM de Hyper-V/Azure (unida a un dominio) Dos fuentes: el host (VMIC) y NTP7 La hora oscila por la doble corrección; gran desviación justo tras una restauración Con host e invitado de 2016 o posterior pueden convivir por defecto. En invitados de 2012 R2 o anteriores, deshabilite VMICTimeProvider3
VM de Hyper-V/Azure (independiente) Igual que arriba Prácticamente sin problemas Use la sincronización con el host tal como viene por defecto3
LAN de fábrica sin conexión Sin origen de sincronización (cada equipo depende de su reloj interno) Todos los equipos derivan de forma independiente Alinee todos los equipos (PC y dispositivos) con un servidor NTP local como referencia. Registre periódicamente el desfase con el reloj de los dispositivos
Se necesita determinar el orden con precisión de ms — La precisión de la sincronización horaria no basta Verifique las condiciones de Windows Server 2016 o posterior más configuración de alta precisión4. Si es posible, oriente el diseño a medir con Stopwatch en una única máquina

8. Resumen

  • La hora de Windows la gestiona w32time: en un dominio, mediante sincronización jerárquica con el emulador de PDC en la cúspide; en un grupo de trabajo, mediante sincronización de baja frecuencia con time.windows.com por defecto. Una desviación de decenas de segundos no es una avería, sino consecuencia de la configuración predeterminada.
  • La investigación empieza por comprobar el origen y la última hora de sincronización con w32tm /query /status, y por medir de forma real la diferencia con otro equipo mediante w32tm /stripchart. Para indicar explícitamente el origen de sincronización use /config /manualpeerlist, y para aplicarlo de inmediato, /resync.
  • w32time corrige las desviaciones pequeñas mediante slew y las grandes mediante step. Tenga presente que el reloj del sistema puede saltar también hacia atrás, y que si se supera el límite, no se aplica corrección alguna.
  • Históricamente, el objetivo de precisión de la configuración predeterminada era apenas cumplir los «5 minutos de Kerberos». El nivel de 1 ms entra dentro del ámbito de soporte a partir de Windows Server 2016, cuando se cumplen las condiciones de fuente horaria precisa, latencia, número de saltos y carga de CPU.
  • Una máquina virtual dispone de dos fuentes: la sincronización con el host y NTP. Como principio, una VM unida a un dominio debe depender únicamente de la sincronización de dominio (deshabilitando VMICTimeProvider en invitados con sistemas operativos antiguos), mientras que una VM independiente debe mantener la sincronización con el host.
  • Del lado de la aplicación, use UTC para las marcas de tiempo y Stopwatch para el tiempo transcurrido, y registre periódicamente el desfase con el reloj propio de cada dispositivo. Con estos tres puntos se puede dejar atrás las investigaciones de fallos en las que «no se sabe cuál ocurrió primero».

Artículos relacionados

Áreas de consultoría relacionadas

En KomuraSoft LLC atendemos consultas de investigación como «no se puede determinar el orden cronológico de un fallo porque la hora de los registros del dispositivo y del PC no coincide», el diseño de la sincronización horaria en entornos de LAN de fábrica e integración con dispositivos, y el desarrollo y la mejora de software de integración con dispositivos, incluidos los defectos relacionados con tiempos de espera y medición de tiempo.

Referencias

</content>

  1. Microsoft Learn, How the Windows Time Service Works. Sobre w32time como servicio estándar de sincronización horaria de Windows que emplea los algoritmos de la especificación NTP; la jerarquía horaria del bosque de AD DS (miembro → DC → DC del dominio padre → emulador de PDC del dominio raíz del bosque); que los equipos fuera de dominio se sincronizan por defecto con time.windows.com; la autenticación de la hora mediante la clave de sesión de Kerberos; que una fuente horaria indicada manualmente no está autenticada; la disciplina de reloj mediante slew/step; y el uso del puerto UDP 123. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  2. Microsoft Learn, Windows Time service tools and settings. Sobre las distintas opciones del comando w32tm (/query /status, /source, /peers, /configuration; /stripchart; /resync; /config /manualpeerlist /syncfromflags); los indicadores NtpServer (0x1 SpecialInterval, 0x2 UseAsFallbackOnly, 0x8 Client) y la recomendación de usar 0x2 con solo dos servidores; que el valor predeterminado en una configuración independiente es time.windows.com,0x1 con SpecialPollInterval en 604 800 segundos por defecto; la conmutación entre slew y step mediante MaxAllowedPhaseOffset; que al superar MaxPosPhaseCorrection/MaxNegPhaseCorrection (54 000 segundos por defecto en configuración independiente) solo se registra el evento sin corregir; y sobre LocalClockDispersion. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13

  3. Microsoft Learn, Time accuracy improvements for Windows Server 2016. Sobre las mejoras del servicio Hyper-V TimeSync (hora inicial al arrancar o restaurar una VM, corrección del retardo de interrupción, reporte del Stratum del host + 1, y que un invitado 2016 unido a un dominio elige el reloj más preciso); la recomendación de deshabilitar el proveedor de sincronización horaria de Hyper-V en invitados unidos a un dominio con 2012 R2 o anteriores, junto con el ajuste de registro VMICTimeProvider; las directrices para VM de Azure (deshabilitar TimeSync en VM unidas a un dominio, mantener la sincronización con el host en VM independientes); y la comparación por versión de la frecuencia predeterminada de sondeo/actualización del reloj (una vez por semana en configuración independiente de la generación 2012 R2, actualización del reloj cada segundo en 2016). ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10

  4. Microsoft Learn, Support boundary for high accuracy time. Sobre que, antes de Windows 10 1607 / Windows Server 2016, el objetivo de diseño de w32time era la precisión necesaria para cumplir los requisitos de Kerberos v5, quedando la alta precisión fuera de soporte; que a partir de 2016 se admiten precisiones de 1 segundo, 50 ms y 1 ms si se cumplen ciertas condiciones; y sobre los requisitos para 1 ms de precisión (fuente horaria Stratum 1, latencia de red inferior a 0,1 ms, hasta Stratum 5 y 4 saltos, uso de CPU igual o inferior al 80 %, entre otros). ↩ ↩2 ↩3 ↩4

  5. Microsoft Learn, Stopwatch Class (System.Diagnostics). Sobre que Stopwatch es una clase para medir el tiempo transcurrido con precisión, que cuenta ticks mediante un contador de rendimiento de alta resolución cuando el hardware y el sistema operativo lo permiten; que Frequency/GetTimestamp pueden usarse en lugar de QueryPerformanceFrequency/QueryPerformanceCounter; y sobre la medición con GetTimestamp y GetElapsedTime. ↩ ↩2

  6. Microsoft Learn, DateTime.UtcNow Property. Sobre que DateTime.UtcNow devuelve la fecha y hora actuales del equipo (UTC), es decir, el reloj del sistema, y que su resolución depende del temporizador del sistema, en general entre 0,5 y 15 ms. ↩ ↩2

  7. Microsoft Learn, Accurate Time for Windows Server 2016. Sobre que un invitado de Hyper-V elige la mejor fuente horaria entre el proveedor VMIC del host y varios proveedores NTP, atendiendo entre otros al Stratum; que el valor predeterminado en una máquina independiente es time.windows.com; que no puede confiarse en una precisión de 1 ms con fuentes horarias remotas; que w32time solo acepta hasta Stratum 15; y sobre los tres requisitos para una hora precisa (fuente horaria estable, reloj de cliente estable y comunicación NTP simétrica). ↩ ↩2 ↩3 ↩4

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

Los registros del PC y los del dispositivo muestran horas distintas. ¿Qué debo comprobar primero?
Lo primero es ejecutar w32tm /query /status en el PC y comprobar la «Source» (con quién se sincroniza) y la «Last Successful Sync Time» (última sincronización correcta). Si la fuente aparece como Local CMOS Clock o la última sincronización fue hace varios días, ese PC en la práctica no está sincronizado con nada. A continuación, mida la diferencia horaria real frente al otro equipo (el servidor o el puerto NTP del dispositivo) con w32tm /stripchart /computer:equipo /dataonly, para tener en cifras quién está desviado y cuánto. Si el dispositivo tiene un reloj propio, conviene leer su hora mediante la pantalla de configuración o el protocolo de comunicación y registrar la diferencia con la hora del PC; ese dato también sirve para cotejar los registros históricos.
¿Con qué frecuencia se sincroniza la hora un Windows en un entorno de grupo de trabajo?
Los equipos Windows que no pertenecen a un dominio se sincronizan de forma predeterminada con time.windows.com, pero con una frecuencia bastante baja. El valor predeterminado del registro SpecialPollInterval es de 604 800 segundos (una semana) en una configuración independiente, y ni siquiera en un cliente Windows 10 pasa de una vez al día aproximadamente. El reloj interno de un PC puede desviarse con facilidad varios segundos, o incluso decenas de segundos, en el transcurso de un día, así que con esta frecuencia no cabe esperar la precisión necesaria para cotejar registros de negocio. En entornos donde la precisión horaria de los registros importa, la práctica habitual es indicar el servidor NTP interno con w32tm /config /manualpeerlist y acortar el SpecialPollInterval.
En una máquina virtual sobre Hyper-V, ¿la hora debe seguir al host o a NTP?
Un invitado de Hyper-V dispone de dos proveedores de hora: el servicio de integración de sincronización horaria de Hyper-V (VMICTimeSync) y el cliente NTP, y Windows elige el que considera mejor según criterios como el nivel jerárquico (Stratum). El principio para un invitado unido a un dominio es sincronizarse con la jerarquía del dominio (el controlador de dominio); con combinaciones de host e invitado de Windows Server 2016 en adelante, ambos mecanismos pueden convivir sin problema gracias a las mejoras introducidas. Si se usa en un dominio un invitado de Windows Server 2012 R2 o anterior, Microsoft recomienda deshabilitar VMICTimeProvider para depender únicamente de la sincronización de dominio. En una VM independiente de grupo de trabajo, lo más simple y fiable es dejar la sincronización con el host tal como viene por defecto.
¿Qué ocurre si la hora se desvía mucho en un entorno de dominio?
Kerberos, usado para la autenticación de Active Directory, exige de forma predeterminada que la hora del cliente y la del servidor coincidan dentro de un margen de 5 minutos. Si la diferencia supera ese margen, la autenticación falla y dejan de funcionar funciones básicas del dominio, como el acceso a carpetas compartidas o la aplicación de directivas de grupo. Un PC unido al dominio se sincroniza de forma predeterminada según la jerarquía que culmina en el controlador de dominio y, en última instancia, en el emulador de PDC de la raíz del bosque, así que normalmente no llega a producirse una desviación tan grande. Dicho de otro modo, si el propio emulador de PDC no está sincronizado con una fuente horaria externa precisa, todo el dominio terminará «coincidiendo, pero en una hora equivocada», por lo que revisar la configuración de ese nodo superior es fundamental.
¿Por qué no se debe usar DateTime.UtcNow para medir el tiempo transcurrido?
Porque DateTime.UtcNow lee el reloj del sistema y, por tanto, recibe de lleno el efecto de las correcciones de w32time. Cuando la diferencia horaria es grande, w32time no la corrige gradualmente (slew) sino que ajusta el reloj de forma directa (step), y en ese momento la hora puede saltar tanto hacia delante como hacia atrás. Es decir, el tiempo transcurrido calculado restando dos valores de UtcNow puede salir más largo de lo real, más corto, o incluso negativo. Para medir tiempo transcurrido o comprobar tiempos de espera, lo seguro es usar Stopwatch (o Stopwatch.GetTimestamp), que aumenta de forma monótona con independencia del reloj del sistema, y reservar UtcNow exclusivamente para registrar «cuándo ocurrió algo».

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.

Contactar
Volver al blog