ntpd:hora consistentemente incorreta no MacBook Air de meados de 2013
-
29-09-2020 - |
Pergunta
estou a usar Carimbo de hora ICMP no meu MacBook Air de meados de 2013, e preciso que meu relógio tenha uma precisão não inferior a 1 ms.
eu vejo isso ntpd
está em execução, com as configurações padrão e /etc/ntp.conf
contém apenas uma linha, server time.apple.com
, sem sequer quaisquer comentários.
No entanto, se eu correr ntpdate -d time.apple.com
(ou ntpdate -d ntp1.yycix.ca
, que produz a mesma leitura de deslocamento para um determinado horário que o time.apple.com farm faz), sempre como um usuário não root, muitas vezes recebo a leitura de que meu relógio está adiantado em até 6 ms, ou, na maioria frequentemente em torno de 4ms (às vezes 0ms, mas muito raramente).
Por que isso está acontecendo?Não estou nem reiniciando meu MacBook, ele funciona 24 horas por dia, 7 dias por semana, conectado, por que está ntpd
não está marcando a hora corretamente?
Syslog tem o seguinte:
% syslog | fgrep ntp | fgrep -v sudo | tail
Nov 19 12:59:30 mba.cnst ntpd[86861] <Notice>: proto: precision = 1.000 usec
A última vez que verifiquei, 1.000 usec
não é pior que 1 us, que é 0,001ms ou 0,000001s;por que afirma que a precisão é de 0,001 ms, quando na realidade o relógio está atrasado em até 6 ms?
Solução
O server
palavra-chave de ntp.conf(5) pareceria configurar apenas um único servidor, mesmo se o nome do host fornecido resolvesse para mais de um endereço IP.
Parece que o servidor específico que estava sendo selecionado é um 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}
Vou Preferências de data e hora, e fornecer uma lista separada por vírgulas de servidores NTP válidos parece resolver o problema.
Fornecer uma lista separada por vírgulas na GUI resulta em vários server
entradas em /etc/ntp.conf, embora você precise ter certeza de que os próprios nomes de host são diferentes (caso contrário, os nomes de host repetidos não resultam na seleção de nenhum servidor real extra, conforme 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}
Uma lista de servidores está disponível em http://support.ntp.org/servers;você deve tentar selecionar os servidores que estão mais próximos de você, especialmente não apenas geograficamente, mas em termos de rede.
Outras dicas
Os processadores mais recentes têm algumas mudanças de clock da CPU bastante avançadas que podem fazer com que um algoritmo de manutenção de tempo como o ntpd fique desligado em 10 ms ou mais, mesmo se você tiver as configurações ideais e um arquivo de desvio adequado.Acrescente a isso o App Nap, a coalescência do temporizador e outras alterações de eficiência no Mavericks e eu não ficaria surpreso se alguns deles afetassem a cronometragem conforme visto por um processo executado na CPU.
Agora, o relógio individual que você tem no seu Mac realmente não se importa com o tempo e a suspensão da CPU, mas o processo que corrige para uma fonte externa pode.Pelos excelentes comentários abaixo - é provável que o hardware que mantém o tempo esteja isolado de qualquer economia de energia da CPU - https://en.wikipedia.org/wiki/Time_Stamp_Counter#Implementation_in_various_processors
Se o seu relógio for bom o suficiente para você - não há necessidade de entrar em detalhes aqui ou se preocupar com o relógio sincronizado com GPS ou com a precisão e exatidão do nível do sistema operacional em tempo real.O hardware é claramente capaz de chegar a uma fonte externa em até 10s de milissegundos com a infraestrutura NTP típica na maioria dos casos.
Meu entendimento é que a mensagem de depuração é um número limitador de taxa interna em que o código ntpd verifica a velocidade de execução da CPU, e não um relatório de que você está de fato a 1.000 usec da realidade ou mesmo de alguma fonte de referência externa.
Veja os comentários acima do procedimento default_get_precision(vazio) onde afirma:
/*
* 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.
*/