ntpd: hora constantemente incorrecta en la MacBook Air de mediados de 2013

La palabra clave server de ntp.conf (5) parece configurar solo una servidor único, incluso si el nombre de host proporcionado se resuelve en más de una dirección IP.

Parece que el servidor específico que se estaba seleccionando es un PoS.

mba: {4899} ntpdc -s ; ntpdc -sn
     remote           local      st poll reach  delay   offset    disp
=======================================================================
*time.apple.com  129.xx.xxx.xxx   2 4096  377 0.07106  0.000248 0.24763
     remote           local      st poll reach  delay   offset    disp
=======================================================================
*17.151.16.22    129.xx.xxx.xxx   2 4096  377 0.07106  0.000248 0.24763
mba: {4900} ntpdate -d 17.151.16.22 |& tail -1 ; \
?           ntpdate -d time.apple.com |& tail -1 ; \
?           ntpdate -d ntp1.yycix.ca |& tail -1
26 Nov 01:49:13 ntpdate[97738]: adjust time server 17.151.16.22 offset -0.000318 sec
26 Nov 01:49:16 ntpdate[97740]: adjust time server 17.171.4.15 offset -0.006493 sec
26 Nov 01:49:16 ntpdate[97742]: adjust time server 192.75.191.6 offset -0.006443 sec
mba: {4901}

Ir a Fecha & Preferencias de tiempo , y proporcionar una lista separada por comas de servidores NTP válidos parece solucionar el problema.

Proporcionar una lista separada por comas en la GUI da como resultado varias entradas server en /etc/ntp.conf, aunque debe asegurarse de que los nombres de host sean diferentes (de lo contrario, los nombres de host repetidos no producen ningún resultado). servidores reales adicionales seleccionados, según ntpq -p ).

mba: {5104} cat /etc/ntp.conf
server ntp1.yycix.ca
server time.nist.gov
server tick.usask.ca
server tock.usask.ca
server clock.nyc.he.net
mba: {5105} ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+ntp1.yycix.ca   .GPS.            1 u  138  512  377   56.517   -0.662   0.319
-2610:20:6f15:15 .ACTS.           1 u  117  512  377   27.975   -1.774   0.989
+tick.usask.ca   .GPS.            1 u  456  512  377   31.388   -0.636   0.135
*tock.usask.ca   .GPS.            1 u  124  512  377   31.486   -0.864   0.413
-clock.nyc.he.ne .CDMA.           1 u  139  512  377   26.860   -2.161   0.194
mba: {5106}

Una lista de servidores está disponible en enlace ; tienes que intentar seleccionar los servidores que están cerca de ti, especialmente no solo geográficamente, sino también de red.

Los últimos procesadores tienen un cambio de velocidad de reloj de la CPU bastante avanzado que podría hacer que un algoritmo de mantenimiento del tiempo como ntpd esté apagado 10 ms o más, incluso si tiene la configuración óptima y un archivo de deriva adecuado. Agregue a esa aplicación la siesta, la fusión del temporizador y otros cambios de eficiencia en Mavericks y no me sorprendería si algunos de los afectados afectaran la hora, como lo ve un proceso que se ejecuta en la CPU.

Ahora, el reloj individual que tiene en su Mac realmente no se preocupa por el tiempo de la CPU y el tiempo de espera, pero el proceso que corrige a una fuente externa podría. De los excelentes comentarios a continuación, es probable que el hardware de mantenimiento del tiempo esté aislado de cualquier ahorro de energía de la CPU: enlace

Si su reloj es lo suficientemente bueno para usted, no es necesario entrar en detalles aquí ni preocuparse por el reloj sincronizado con GPS o la precisión y exactitud del nivel del sistema operativo en tiempo real. El hardware es claramente capaz de estar dentro de 10s de milisegundos a una fuente externa con la infraestructura típica de ntp en la mayoría de los casos.

Entiendo que el mensaje de depuración es un número de límite de frecuencia interno en el que el código ntpd está verificando la rapidez con la que se ejecuta la CPU y no un informe de que en realidad está a 1000 usec de la realidad o incluso alguna fuente de referencia externa.

Vea los comentarios sobre el procedimiento default_get_precision (void) donde se indica :

/*
 * This routine calculates the system precision, defined as the minimum
 * of a sequence of differences between successive readings of the
 * system clock. However, if the system clock can be read more than once
 * during a tick interval, the difference can be zero or one LSB unit,
 * where the LSB corresponds to one nanosecond or one microsecond.
 * Conceivably, if some other process preempts this one and reads the
 * clock, the difference can be more than one LSB unit.
 *
 * For hardware clock frequencies of 10 MHz or less, we assume the
 * logical clock advances only at the hardware clock tick. For higher
 * frequencies, we assume the logical clock can advance no more than 100
 * nanoseconds between ticks.
 */