Chciałbym wiedzieć, jakie są domyślne ustawienia OS X w zakresie dostosowania zegara, gdy włączę automatyczną synchronizację czasu w preferencjach Data i czas.
Wiem, że czcigodny ntpddemon w Mavericks (10.9) i Yosemite (10.10) nie jest już odpowiedzialny za regulację czasu, a zamiast tego wprowadzono nowy program pacemaker- więc skąd mam wiedzieć, że coś działa lub potrzebuję korekty, aby zachować czas?
Odpowiedzi:
Mojave nadal korzysta timed, ale ntpdatepomocnicy ntpqzostali usunięci. Aby sprawdzić i zaktualizować czas systemowy, możesz zadzwonić sntpbezpośrednio.
$ sudo sntp -sS pool.ntp.org
Password:
sntp 4.2.8p10@1.3728-o Tue Mar 21 14:36:42 UTC 2017 (136.200.1~2533)
2018-09-29 19:42:41.448103 (-0200) +1087.742403 +/- 725.183462 pool.ntp.org 188.68.36.203 s2 no-leap
Po wyjęciu z pudełka brakuje pliku śledzenia, więc jeśli pojawi się ten nieszkodliwy błąd podczas sprawdzania czasu:
kod_init_kod_db(): Cannot open KoD db file /var/db/ntp-kod: No such file or directory
zignoruj błąd lub spróbuj utworzyć ten pusty plik:
sudo touch /var/db/ntp-kod
sudo chmod 666 /var/db/ntp-kod
High Sierra korzysta timedz /usr/libexec/timed, prowadzonego przez użytkownika systemu _timed.
timed utrzymuje dokładność zegara systemowego poprzez synchronizację zegara z zegarami odniesienia za pomocą technologii takich jak NTP. Dane wejściowe są scalane w ramach czasowych, gdzie oblicza niepewność, aby ułatwić planowanie zadań w czasie proaktywnym. timed jest również świadomy stanu zasilania / akumulatora.
timed jest zarządzany przez LaunchDaemon /System/Library/LaunchDaemons/com.apple.timed.plist. biegi czasowe…
Możesz zobaczyć, jak „wyłączony” jest Twój zegar, patrząc na zawartość /var/db/timed/com.apple.timed.plistsłownika TMLastSystemTime w kluczu TMTimeError i kluczu TMScaleFactorError.
$ sudo defaults read /var/db/timed/com.apple.timed TMLastSystemTime
{
TMCurrentTime = "537303485.281592";
TMReliability = 1;
TMRtcTime = "351422.381868388";
TMScaleFactor = "0.9999958233107684";
TMScaleFactorError = "3.468751755688052e-05";
TMSource = TMTimeSynthesizer;
TMTimeError = "0.6127951619022057";
}
timed korzysta z ustawionego serwera czasu /etc/ntp.conf, którym jest domyślnie
server time.apple.com
timed używa również TMTimeSynthesizer, czegoś, co CoreTime na iOS używa do aktualizacji zegara, ale nie jestem świadomy jego historii na macOS:
Nie uruchamiaj binarnego timera sam, jak wspomniano na stronie podręcznika:
timed nie przyjmuje żadnych argumentów, a użytkownicy nie powinni uruchamiać go ręcznie.
Według użytkowników forów programistów Apple granada29 w poście ntpd, chronometraż i chronyd w 10.13 , timed wykonuje następujące czynności:
timed wydaje się być prostym klientem sntp - tj. okresowo sonduje NTP (15 minut) i używa wywołania systemowego settimeofday () do ustawienia zegara systemowego. Zakładam, że jest trochę sprytny, aby uniknąć cofania zegara do tyłu, ale nie ma sposobu, aby powiedzieć.
pacemakerjest demonem odpowiedzialnym za zarządzanie czasem w macOS. Służy adjtimedo dostosowania zegara do zawartości /var/db/ntp.drift.
Możesz zobaczyć, jak „wyłączony” jest Twój zegar, patrząc na zawartość ntp.drift- na przykład mój plik zawiera następujące elementy:
-23.640
Oznacza to, że zegar jest o -23.64 PPM od czasu, który powinien być. Jednostkami tej liczby są PPM lub części na milion. 1 PPM to 1 mikrosekunda / sekundę lub 3,6 ms / h.
Możesz częściej aktualizować zegar, uruchamiając pacemakertę -aopcję, zapewniając w sekundach czas oczekiwania między ruchami czasu:
/usr/libexec/pacemaker -a 10
Aby zobaczyć parametry używane przez OS X dla stymulatora serca, otwórz /System/Library/LaunchDaemons/com.apple.pacemaker.plist.
{
KeepAlive = { PathState = { "/private/var/db/ntp.drift" = :true; }; };
Label = "com.apple.pacemaker";
ProgramArguments = ( "/usr/libexec/pacemaker", "-b", "-e", "0.0001", "-a", "10" );
}
Aby znaleźć bieżące ustawienia, uruchom z -iopcją:
/usr/libexec/pacemaker -i
Jan 19 18:20:08 g pacemaker[12544] <Info>: --- settings for external power ---
Jan 19 18:20:08 g pacemaker[12544] <Info>: interval = 1 seconds, tolerance = 0.000000, drift = -23.640000
Jan 19 18:20:08 g pacemaker[12544] <Info>: --- settings for internal power ---
Jan 19 18:20:08 g pacemaker[12544] <Info>: interval = 1 seconds, tolerance = 0.000024, drift = -23.640000
Możesz wyświetlić dziennik, uruchamiając z -vopcją:
sudo /usr/libexec/pacemaker -v
Password:
Jan 19 18:23:17 g pacemaker[13202] <Info>: power status check: using external power
Jan 19 18:23:17 g pacemaker[13202] <Info>: created file monitor for /var/db/ntp.drift
Jan 19 18:23:17 g pacemaker[13202] <Info>: interval = 1 seconds, tolerance = 0.000000, drift = -23.640000
Jan 19 18:23:19 g pacemaker[13202] <Debug>: drift -23.640000 residue 0.000000 delta -23
Jan 19 18:23:20 g pacemaker[13202] <Debug>: drift -23.640000 residue -0.640000 delta -24
Jan 19 18:23:21 g pacemaker[13202] <Debug>: drift -23.640000 residue -0.280000 delta -23
Jan 19 18:23:22 g pacemaker[13202] <Debug>: drift -23.640000 residue -0.920000 delta -24
Jan 19 18:23:23 g pacemaker[13202] <Debug>: drift -23.640000 residue -0.560000 delta -24
Jan 19 18:23:24 g pacemaker[13202] <Debug>: drift -23.640000 residue -0.200000 delta -23
⌃C%
Szczegóły mogą być pomocne w celach informacyjnych, ale inna odpowiedź doskonale obejmuje nowsze szczegóły pomiaru czasu w systemie macOS.
Pierwszym krokiem jest sprawdzenie, czy Twój czas jest skonfigurowany.
Mac:~ me$ ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*time.apple.com 17.168.198.149 2 u 1046 512 37 58.475 9.477 3.674
Zakładając, że masz opóźnienie / przesunięcie / drgania mniejsze niż 100 (opóźnienie może być mniejsze niż 1000 w normalnych sytuacjach dla mniej krytycznych systemów o dokładności czasowej), po następnym poleceniu do uruchomienia w terminalu ntpqnastępuje serwer czasu z twojego ntpqi preferencji systemowych. Możesz także przetestować inne serwery czasu, aby sprawdzić, czy mają one mniejsze opóźnienia, ponieważ system pomiaru czasu lubi mieć szybką i szybką odpowiedź od serwerów czasu podczas korygowania czasu różnic milisekundowych i obliczania, w jaki sposób bieżący zegar sprzętowy odchodzi od czasu standardowego .
Mac:~ me$ ntpdate -q time.apple.com
server 17.151.16.12, stratum 2, offset 0.081698, delay 0.11237
server 17.151.16.20, stratum 2, offset 0.081365, delay 0.11310
server 17.151.16.21, stratum 2, offset 0.082754, delay 0.11440
server 17.151.16.22, stratum 2, offset 0.081750, delay 0.11264
server 17.151.16.23, stratum 2, offset 0.082691, delay 0.11415
server 17.151.16.38, stratum 2, offset 0.082077, delay 0.11458
server 17.171.4.13, stratum 2, offset 0.084822, delay 0.08054
server 17.171.4.14, stratum 2, offset 0.083749, delay 0.08142
server 17.171.4.15, stratum 2, offset 0.086343, delay 0.07605
server 17.171.4.33, stratum 2, offset 0.086526, delay 0.07690
server 17.171.4.34, stratum 2, offset 0.084500, delay 0.07997
server 17.171.4.35, stratum 2, offset 0.083987, delay 0.08278
server 17.171.4.36, stratum 2, offset 0.084382, delay 0.08028
server 17.171.4.37, stratum 2, offset 0.085948, delay 0.07831
server 17.151.16.14, stratum 2, offset 0.082043, delay 0.11270
19 Jan 12:09:32 ntpdate[4592]: adjust time server 17.171.4.15 offset 0.086343 sec
Mac:~ me$ ntpq
ntpq> assoc
ind assid status conf reach auth condition last_event cnt
===========================================================
1 57788 9014 yes yes none reject reachable 1
ntpq> peer
remote refid st t when poll reach delay offset jitter
==============================================================================
time.apple.com 17.168.198.148 2 u 729 512 1 133.274 51.653 371.362
ntpq> q
Następną rzeczą do sprawdzenia jest program stymulatora serca:
Mac:~ me$ ps -ef|grep [p]acemaker
0 76 1 0 Fri08AM ?? 0:03.64 /usr/libexec/pacemaker -b -e 0.0001 -a 10
To pokazuje, że w przypadku baterii interwał regulacji wynosi nie więcej niż raz na 10 sekund, a regulacja jest jeszcze mniejsza, jeśli błąd zegara jest mniejszy niż 0,1 milisekundy.
Jeśli okaże się, że przesunięcie wynosi kilka sekund lub dłużej, możesz zmienić używane serwery czasu lub zmienić wartości używane w stymulatorze, aby zużywać więcej energii i procesora, ale masz zegar bliższy rzeczywistemu czasowi w zamian za ustawienia, które Apple ma wysłane z 10.9.
Jeśli przejdziesz na http://time.gov , możesz zobaczyć oficjalny czas (do sekundy) i użyć go do sprawdzenia, czy czas systemowy jest poprawny, czy nie. Zauważ, że jest to oficjalny czas NIST i wykonuje on własną synchronizację w przeglądarce, niezależnie od czasu systemowego (na przykład widać tutaj, że time.gov obsługuje sekundy przestępne, podczas gdy OS X najwyraźniej nie).
Począwszy od High Sierra demon systemowy ntpd został zastąpiony demonem systemowym, który wywołuje / usr / libexec / timed.
Najlepszym exec, jaki znalazłem, aby uzyskać szczegółowe informacje, jest systemsetup(uruchom jako root) z jego różnymi flagami:
[-getusingnetworktime] [-setusingnetworktime on | off]
[-getnetworktimeserver] [-setnetworktimeserver timeserver]
Wynikowy wynik jest zdecydowanie mniej szczegółowy (= nudny). Np. Brak szczegółów ∂T / driftu.
Najwyraźniej czas korzysta tylko z jednego serwera ntp (pierwszy wymieniony na liście - sprawdzony za pomocą WireShark / LittleSnitch), nawet jeśli kilka jest wpisanych w pliku preferencji systemowych / ntp.conf.
Dalsza lektura (niezbyt techniczna): Czy ktoś ma czas? Jak High Sierra zmieniła synchronizację czasu
Wcześniejszy demon ntpd jest nadal obecny, ale nie jest rozładowany. Można go jednak załadować, wprowadzając w Terminal.app:
sudo launchctl load [-F|-w] /System/Library/LaunchDaemons/org.ntp.ntpd-legacy.plist
w trybie wyłączonym SIP. Wprowadzanie ntpq -pbędzie wtedy działać ponownie.
Aby załadować demona w trybie SIP, skopiuj plik do / Library / LaunchDaemons /:
sudo cp /System/Library/LaunchDaemons/org.ntp.ntpd-legacy.plist /Library/LaunchDaemons/org.ntp.ntpd.plist
Zmodyfikuj etykietę plist za pomocą nano lub innego edytora z org.ntp.ntpd-legacy na org.ntp.ntpd:
sudo nano /Library/LaunchDaemons/org.ntp.ntpd.plist
Załaduj demona:
sudo launchctl load -w /Library/LaunchDaemons/org.ntp.ntpd.plist
Jeśli znajdę lepszego exec, aby uzyskać szczegółowe informacje o czasie z domyślnym demonem High Sierra, odpowiedź zostanie zaktualizowana.
Aby uzyskać wiarygodną odpowiedź na temat tego, jak dobrze ustawiony jest zegar, uruchom program ntpdate w trybie debugowania:
ntpdate -d pool.ntp.org
To będzie wirować przez chwilę i skończy się na linii, takiej jak
1 Apr 17:38:16 ntpdate[4711]: adjust time server 123.45.67.89 offset 0.000810 sec
W tym przypadku oznaczało to, że mój zegar lokalny wyłączył jakieś 810 µs (co byłoby spektakularne, jeśli faktycznie prawdziwe, ale wartość znacznie poniżej 100 ms wskazuje na działającą synchronizację).
Aby sprawdzić synchronizację zegara, podobną do odpowiedzi, która sugeruje uruchomienie ntpdatew trybie debugowania, możesz również uruchomić ją w trybie zapytania, aby uzyskać mniej szczegółowe dane wyjściowe.
$ ntpdate -q pool.ntp.org
server 85.199.214.102, stratum 1, offset 0.006256, delay 0.05470
server 95.215.175.2, stratum 3, offset 0.005234, delay 0.05624
server 217.114.59.3, stratum 2, offset 0.007166, delay 0.06274
server 85.199.214.100, stratum 1, offset 0.006319, delay 0.05396
22 Jun 09:20:55 ntpdate[84112]: adjust time server 85.199.214.100 offset 0.006319 sec
$
Pochodzi z mojego komputera Mac z systemem High Sierra 10.13.2, który działa timedraczej niż demon NTP ( ntpdatenadal działa, ponieważ nie używa demona NTP).
sntpdziała. Zastanawiam się, czy/var/db/ntp-kodbłąd nie powoduje problemów z automatyczną synchronizacją - spróbuję go utworzyć i sprawdzi za kilka miesięcy. =)