ntpd: tempo costantemente errato su MacBook Air a metà 2013

La parola chiave server di ntp.conf (5) sembrerebbe configurare solo un server singolo, anche se il nome host fornito risolve più di un indirizzo IP.

Sembra che il server specifico che è stato selezionato sia 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}

Verso Data e amp; Preferenze del tempo e la fornitura di un elenco separato da virgole di server NTP validi sembra risolvere il problema.

Fornendo un elenco separato da virgole nella GUI si ottengono diverse voci server in /etc/ntp.conf, sebbene sia necessario assicurarsi che i nomi host siano diversi (altrimenti, i nomi host ripetuti non risultano in nessun server effettivi in più selezionati, come per 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}

Un elenco di server è disponibile al link ; devi provare a selezionare i server che ti sono vicini, soprattutto non solo geograficamente, ma in termini di rete.

Gli ultimi processori hanno uno spostamento della frequenza di clock della CPU abbastanza avanzato che potrebbe rendere un algoritmo di mantenimento del tempo come ntpd essere spento a 10ms o più anche se si dispone delle impostazioni ottimali e di un file di deriva adeguato. Aggiungete a quell'app Nap, coalescenza temporizzata e altre modifiche di efficienza a Mavericks e non sarei sorpreso se alcuni di quei timekeeping interessati si manifestassero in un processo eseguito sulla CPU.

Ora, l'orologio individuale che hai sul tuo Mac non si preoccupa del timing della CPU e del sonno, ma potrebbe essere il processo che si corregge su una fonte esterna. Dai commenti eccellenti qui sotto - è probabile che il tempo di mantenere l'hardware sia isolato da qualsiasi risparmio di energia della CPU - link

Se il tuo orologio è abbastanza buono per te - non è necessario entrare nei dettagli qui o preoccuparti dell'orologio sincronizzato GPS o della precisione e precisione del livello OS in tempo reale. Nella maggior parte dei casi, l'hardware è chiaramente in grado di trovarsi entro 10 secondi di millisecondi verso una fonte esterna con la tipica infrastruttura NTTP.

La mia comprensione è che il messaggio di debug è un numero che limita la velocità internamente dove il codice ntpd sta controllando la velocità di esecuzione della CPU, e non alcuni riferiscono che si è in realtà 1.000 usec dalla realtà o anche qualche fonte di riferimento esterna. p>

Vedi i commenti sopra la procedura default_get_precision (void) dove si afferma :

/*
 * 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.
 */