Synchronizować zegar z NTP w trybie online, a RTC w trybie offline?

Czy istnieje istniejący mechanizm synchronizujący system linuksowy z NTP w trybie online oraz z przewidywalnym dryfowaniem RTC w trybie offline?

Obsługujemy zdalne „kolektory”: wbudowane systemy Linux, które zbierają i znaczniki czasowe danych czujnika. Potrzebujemy błędów zegara, aby pozostały na stosunkowo niskim poziomie, powiedzmy poniżej 5 sekund. Zwykle używamy NTP do synchronizowania ich zegarów, a to działa dobrze - dopóki system jest w trybie online.

Problem polega na tym, że niektóre kolektory mają bardzo złe łącza wysyłające, które mogą zejść na godziny, dni lub nawet tygodnie. To nie zatrzymuje lokalnego gromadzenia danych, ale bez NTP zegar systemowy w Linuksie dryfuje źle i dość nieprzewidywalnie.

OTOH, RTC sprzętu również mocno dryfuje, ale w stałym tempie. Szybkość dryfu RTC różni się w zależności od deski, ale jest stała dla każdej deski i może być mierzona.

Chyba potrzebujemy mechanizmu, który wykonuje następujące czynności:

• Zmierz współczynnik dryfu RTC tablicy przed jej wdrożeniem
• Dostosuj czas systemowy w sposób ciągły / regularnie za pośrednictwem NTP, jeśli to możliwe
• Regularnie dostosowuj czas systemowy z RTC, gdy NTP jest niedostępny. Weź pod uwagę znaną prędkość dryfu RTC.
• Opcjonalnie: Mierz i rejestruj współczynnik dryfu RTC trwający w trybie online (1)

Przez „mechanizm” mam na myśli dobrze utrzymane, udokumentowane oprogramowanie i / lub konfigurację, które mogą obsługiwać dwa stany „online” vs. „offline”, zapewnić synchronizację zegara systemowego z właściwym źródłem czasu (ntp vs. rtc), wykrywa zmianę stanu i poprawia dryf RTC. Nie ma większego znaczenia, czy jest on zaimplementowany jako specjalna konfiguracja / wtyczka ntpd, jako osobny demon, jako zadanie cron, czy też.

Spojrzałem na Chrony , ale zgodnie z jego dokumentacją próbuje przewidzieć dryf zegara systemowego , który w naszym przypadku dryfuje o wiele bardziej nieprzewidywalnie niż RTC. Wydaje się, że Chrony korzysta z RTC tylko po to, aby utrzymać czas podczas restartów.

(1) Uwaga: ntpd aktywuje „11-minutowy tryb” jądra (aktualizuj rtc z zegara systemowego co 11 minut). Wydaje się, że nie ma sposobu, aby obecne jądra i ntpd zapobiegły trybowi 11-minutowemu. Dlatego wszelkie informacje dotyczące dryfu rtc są tracone podczas działania ntpd (thx @billthor).

Aktualizacje / Edycje:

• Rozważamy dodanie zewnętrznego zegara radiowego dla sygnału MSF lub DCF77 (z siedzibą w Europie) przez USB lub szeregowy. Ale raczej staramy się, aby sprzęt był ubogi.
• Nasze kolektory znajdują się w pomieszczeniach, często w piwnicy. Dodanie zegarów GPS nie pomoże.
• Używamy Debiana 7. To oznacza hwclock z util-linux-2.20.1, ntpdate-4.2.6p5, ntpd z ntp-4.2.6.p5, chrony-1.24 (potencjalnie 1.30).
• Należy pamiętać, że naszym problemem nie jest to, że nie wiemy, jak używać ntpdate(8), hwclock(8), date(1), itd. Proszę zobaczyć dodatkową sekcję kursywą o co mi chodzi z „mechanizmem”.
• Dodano przypis dotyczący trybu „11 minut”
• Oto bardzo interesująca dyskusja na temat synchronizacji offline i dryfu RTC

Twoja sytuacja jest niezwykła i byłbym zaskoczony, gdyby ktoś wymyślił standardową ntpdkonfigurację do robienia tego, co chcesz. To powiedziawszy, lubię być zaskoczony i zdarza się to dość często wokół tych części.

Ale dopóki ktoś nie wpadnie na lepszy pomysł, czy zastanawiałeś się nad takim crontabwpisem?

*/5 * * * *   ntpdate 0.pool.ntp.org || ( hwclock --adjust; hwclock --hctosys )

IE, co pięć minut spróbuj zsynchronizować zegar ntpdate, a jeśli (i tylko jeśli) to się nie powiedzie, dostosuj zegar sprzętowy do dryfu zgodnie z /etc/adjtimeplikiem (którego format jest szczegółowo opisany man hwclocki którego pierwszą linię wypełniłeś odpowiednio, korzystając ze swojej wiedzy określonej częstotliwości RTC), a następnie ustaw zegar systemowy z RTC.

Pamiętaj, że jeśli zdecydujesz się na takie rozwiązanie i wdrożysz dowolną znaczną liczbę tych systemów, uważanie za godne uwagi jest praca z pulą i przekazywanie serwerów proporcjonalnie do zużycia. Więcej informacji można znaleźć na stronie http://www.pool.ntp.org/en/vendors.html .

NTP ma już mechanizmy umożliwiające sprawdzenie, czy jest online czy offline, i w razie potrzeby przełączy się na źródła o niższym priorytecie. Bardzo łatwo jest sprawdzić wartość zasięgu, aby uruchomić alternatywne źródło, ale trzymałbym się NTP. Jak omówiono poniżej, monitorowanie i korygowanie dryfu RTC może być trudne.

W czasach przed Internetem korzystałem z programu, który dzwonił do źródła danych i synchronizował zegar. Nadal mogą być dostępne usługi, które zapewniają źródło czasu przez modem. Wymagałoby to dostępu do linii telefonicznej.

Znane są problemy z zegarem lokalnym, które nie dotyczą RTC. Niektóre problemy są udokumentowane na liście znanych problemów z systemem operacyjnym NTP . Mogą one uwzględniać przesunięcie zegara. Ich rozwiązanie może rozwiązać problem. Wobec braku pominiętych tyknięć, lokalne (systemowe) źródło czasu może być bardzo stabilne.

Możesz być w stanie użyć sterownika zegara Dumb (33) z programem, który zapisuje odpowiedni czas RTC na urządzeniu / dev / dumbclockX.

Istnieje wiele innych sterowników opartych na zegarach radiowych. Niektóre z nich korzystają z usług krótkofalowych, takich jak WWV i CHU, które mogą działać w środowiskach, w których sygnały GPS są niedostępne. W Europie lista ta obejmowałaby BBC, TDF, RBU i RMW.

Pavel Krejci napisał również sterownik RTC, ale nie wydaje się, aby był włączony do oficjalnych sterowników. Może to działać z synchronizacją typu PPS.

Przed wdrożeniem powinien być możliwy pomiar dryfu RTC. Musisz jednak upewnić się, że RTC nie jest automatycznie aktualizowany. Gdy zegar systemowy jest aktualizowany za pomocą funkcji adjtimex, RTC może być aktualizowany co 11 minut.

NTP zaktualizuje zegar, gdy zostanie podłączony. Zwykle NTP odmawia dokonania dużych korekt zegara systemowego. Dostępne są opcje regulacji zakresu regulacji zegara.

Zasugerowałem opcje użycia RTC powyżej. Zegar radiowy może być bardziej odpowiedni niż zegar GPS.

Pomiar znoszenia przy braku wiarygodnego źródła czasu do porównania jest prawdopodobnie daremnym wysiłkiem. Jeśli czas lokalny jest niestabilny, nie można go używać do monitorowania RTC i odwrotnie. Pomiar dryfu przy podłączonym NTP nie będzie działał, jeśli jądro aktualizuje RTC co 11 minut. Użyte przeze mnie RTC mają jednosekundową rozdzielczość, więc musiałyby znacznie dryfować, aby były niezawodnie mierzalne.