Al habilitar Windows para configurar la hora del sistema a través de Internet, aparece el siguiente cuadro de diálogo:
¿Importa qué servidor de hora elijo?
¿Cómo puedo saber si uno es "mejor" que los demás?
Respuesta1
¿Importa qué servidor de hora elijo?
Respuesta corta: sí
Si bien todos los servidores NTP se esfuerzan por mantener la sincronización con UTC, su distancia de usted y de las redes intermedias afectan factores NTP como la latencia y la fluctuación. También está la cuestión de la disponibilidad, no todos los servidores están disponibles continuamente para siempre.
Hasta donde yo sé, UTC y el servicio NTP estratum-0 no están supervisados, regulados ni proporcionados por USNO, ni siquiera dentro de los EE. UU. UTC fue definido por la UIT y se basa en TAI más segundos intercalares (creo que determinados por ERS). TAI es mantenido por un conjunto internacional de 70 laboratorios (de los cuales USNO es uno, pero también incluye NRL en Washington y NIST en Boulder) y coordinado. por BIPM en Francia.
Yo usaría elpiscina ntppara su localidad.
¿Cómo puedo saber si uno es "mejor" que los demás?
Ejecutando un cliente NTP real en un sistema adecuado y observando las estadísticas
# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
connorw600.info europium.canoni 16 u 182d 1024 0 0.000 0.000 4000.00
*dns0.rmplc.co.u ntp1.ja.net 2 u 659 1024 377 27.015 -4.936 1.034
+82.113.154.206 ntp4.ja.net 2 u 700 1024 377 24.853 -4.827 0.788
+dawn.rt.uk.eu.o ntp1.nl.uu.net 2 u 913 1024 377 29.364 -5.614 0.691
Parece que connorw600.info… sería una mala elección.
Respuesta2
Según Wikipedia, elProtocolo de tiempo de redfunciona de la siguiente manera:
Para sincronizar su reloj con un servidor remoto, el cliente NTP debe calcular el tiempo de retraso de ida y vuelta y el desplazamiento. El retraso de ida y vuelta se calcula como
, donde
es el tiempo de transmisión del paquete de solicitud,
es el tiempo de recepción del paquete de solicitud,
es el tiempo de transmisión del paquete de respuesta y
es el tiempo de recepción del paquete de respuesta.
es el tiempo transcurrido en el lado del cliente entre la emisión del paquete de solicitud y la recepción del paquete de respuesta, mientras que
es el tiempo que el servidor esperó antes de enviar la respuesta. El desplazamiento viene dado por
.
La sincronización NTP es correcta cuando tanto las rutas entrantes como salientes entre el cliente y el servidor tienen un retardo nominal simétrico. Si las rutas no tienen un retraso nominal común, la sincronización tiene un sesgo sistemático de la mitad de la diferencia entre los tiempos de viaje hacia adelante y hacia atrás.
A partir de esta explicación podemos admitir que para tener una sincronización de reloj precisa debe tener una baja diferencia en el tiempo de demora en que el servidor responde a su solicitud y el tiempo de demora en que usted responde al servidor para completar la sincronización. Entonces, si el servidor que está ejecutando está lejos de usted (quiero decir, hay muchos "puntos" o enrutadores entre usted y el servidor NTP), la probabilidad de tener una "ruta" diferente para los paquetes NTP que está recibes y envías se incrementa.
Entonces, según mi interpretación del caso, el mejor servidor para sincronizar tu reloj es el "más cercano". Es decir, si obtienes un rastro de los "puntos" entre tú y el servidor elegirías el que tenga menos saltos. Puede utilizar el comando "tracert" de Windows para resolver cuál es el mejor servidor NTP público para usted.
Además, recuerde que más allá de estas opciones estándar, existenmuchos servidores NTP públicosEn Internet.
Respuesta3
Respuesta corta: No.
No importa. Son todos iguales. Más o menos, son respaldo el uno del otro. En los Estados Unidos, el Departamento de Servicio de Tiempo del Observatorio de la Marina de los EE. UU. es el cronometrador oficial. Todos los demás reflejan su época, incluidas las corporaciones y, especialmente, cualquier entidad gubernamental de EE. UU. Por lo tanto, todas las opciones disponibles en el menú desplegable son al mismo tiempo. De ahí que no haya uno que sea "mejor" que los demás.
Respuesta4
En realidad, existe una gran diferencia en la latencia. El uso del grupo, por ejemplo, puede introducir una latencia variable. El grupo intenta conectarlo a un servidor cercano. En mi experiencia, el tiempo de "búsqueda" varía de una consulta a otra. En una de mis aplicaciones, me vi obligado a hacer del grupo una copia de seguridad de tercer nivel porque Google y Microsoft tenían una latencia más consistente.