Jak dostosować częstotliwość odpytywania NTP?

Konfiguruję Ubuntu na maszynie osadzonej, która działa przez połączenie komórkowe, gdzie płacimy za bajt. Maszyna nie ma również baterii RTC, więc zaczyna się od przypadkowego czasu przy każdym uruchomieniu.

Chciałbym się upewnić, że czas zostanie zsynchronizowany, gdy połączenie komórkowe będzie dostępne, aby wiadomości dziennika itp. Miały czas rzeczywisty, ale nie chcę też płacić za ruch NTP za ramię i nogę.

Czy mogę dostosować szybkość, z jaką NTP aktualizuje czas? Obecnie używam openntpd, ale nie jestem do tego przywiązany.

Internet niekoniecznie jest uruchomiony przy starcie, więc ntupdate i powiązany podczas uruchamiania nie będą działać. A planowanie za pomocą crona oznacza oczekiwanie na rozpoczęcie zaplanowanego zadania, podczas gdy chcę, aby demon czasu zsynchronizował się jak najszybciej.

Niektóre z tych odpowiedzi mogą wygrać zawarty w zaciemnieniu konkurs konfiguracji NTTP.

Użyj implementacji ntp i użyj iburst, aby szybko ustawić czas po uruchomieniu. Następnie możesz użyć dyrektywy minpoll, aby ograniczyć częstotliwość wysyłania zapytań do zdalnych serwerów czasu przez ntpd. Pozwoli ci to wykorzystać dyscyplinę zegara ntpd i zmniejszyć przepustowość.

minpoll minpoll
maxpoll maxpoll
    These options specify the minimum and maximum poll intervals for NTP 
    messages, in seconds as a power of two. The maximum poll interval 
    defaults to 10 (1024 s), but can be increased by the maxpoll option to 
    an upper limit of 17 (36 h). The minimum poll interval defaults to 6 (64 s), 
    but can be decreased by the minpoll option to a lower limit of 3 (8 s).

Chrony to dobra alternatywa dla implementacji referencji NTTP . Openntpd nie jest.

Moje doświadczenie dotyczy raczej ntp niż openntpd.

Powinieneś wiedzieć, że protokół NTP zwykle zaczyna się od wysyłania pakietów co minutę (64 sekundy), ale zwykle ustala się, wysyłając i odbierając jeden pakiet co 17 minut dla każdego serwera, który masz w pliku /etc/ntp.conf. Awarie sieci lub niestabilny zegar w urządzeniu mogą to jednak zwiększyć. Każdy pakiet ma pojemność około 68 bajtów, więc jest to prawdopodobnie nieco ponad 100 bajtów w jedną stronę na sondę.

Rdate i ntpdate w czasie konfiguracji sieci są dobrym pomysłem na ustawienie czasu. A jeśli to wszystko, czego potrzebujesz, powinno dobrze dla ciebie działać.

Jeśli jednak chcesz zsynchronizować czas przez dłuższy czas, protokół NTTP został tak zaprojektowany. Zegar w twoim urządzeniu będzie działał trochę szybko lub wolniej, w zależności od tego, jak będzie ciepło lub zimno, mimo że prawdopodobnie ma zegar sterowany kryształem - a ciągłe mierzenie czasu ma to na celu.

Oto kilka sugestii, jeśli potrzebujesz ciągłego pomiaru czasu i chcesz zmniejszyć używane pasmo. Odnoszą się do elementów w ntp.conf.

Nie używaj iburst. (Ale ustawienie czasu zajmie więcej czasu).

Zwiększ minpoll w górę z 6 (2 ^ 6 sekund to 64 sekund). Zmniejsza to ruch, gdy protokół uruchamia się po uruchomieniu sieci.

Zwiększ maxpoll w górę z 10 (2 ^ 10 sekund to 1024 sekundy lub co około 17 minut. Możesz przejść do 17, aby sondować co 36 godzin. Sam tego nie próbowałem.

Używaj tylko minimalnej liczby serwerów, jeśli masz taki, na którym można w wiarygodny sposób uzyskać dostęp z urządzeń wbudowanych, byłoby świetnie. Im więcej serwerów, tym bardziej wiarygodne może być mierzenie czasu, ale ruch rośnie, więc jest to kompromis.

Możesz zrobić hackery polegające na uruchomieniu ntpdate, gdy pojawi się interfejs komórki. Ale jeśli możesz, instalowanie chrony byłoby lepszą alternatywą, ponieważ zostało stworzone z myślą o przerywanym dostępie do sieci .

W domyślnej instalacji Ubuntu demon NTP nie działa. Zamiast tego czas jest ustawiany za każdym razem, gdy /etc/network/if-up.d/ntpdatehak podnosi interfejs sieciowy .

Jeśli wolisz jednorazową synchronizację czasu niż stałą synchronizację, to może ci wystarczyć.

Możesz kontrolować, które serwery są pytane o ustawienie czasu, albo poprzez standardowy /etc/ntp.confplik, albo poprzez NTPSERVERSzmienną w /etc/default/ntpdate.

Czy potrzebujesz dokładnej i precyzyjnej synchronizacji, którą zapewnia ntp? Jeśli nie, możesz być w stanie uciec przy użyciu rdatelub ntpdatepodczas rozruchu, a następnie okresowo przez cron.

Prawdopodobnie już przeczytałeś stronę manuala openntpd.

http://www.openbsd.org/cgi-bin/man.cgi?query=ntpd.conf

Prawdopodobnie już zauważyłeś brak opcji odpytywania o czas.

Mam te możliwe hacki do zaproponowania:

1. Nie używaj żadnego ntpd, po prostu wywołaj ntpdate przez cron.

2. Użyj crona i / lub skryptów połączenia komórkowego, aby przełączyć reguły iptables, aby upuszczać lub zezwalać na ruch na porcie 123, kiedy chcesz. To może być tak proste jak

   0 12 * * * iptables -D OUTPUT -j DROP -p udp --dport 123 # at noon start allowing ntp

   0 13 * * * iptables -A OUTPUT -j DROP -p udp --dport 123 # at 1pm stop allowing ntp

3. Osadź odbiornik zegara radiowego we wbudowanym urządzeniu. Nie wiem o tym prawie nic, ale takie produkty:

   • http://www.galsys.co.uk/time-receivers/ac-500-msf-time-receiver.html i to

   • http://www.giangrandi.ch/electronics/dcf77/dcf77.shtml i ludzie mówią tak

   • http://www.blu.org/cgi-bin/calendar/2010-oct

spraw, żebym pomyślał, że nie jest trudno odbierać sygnał radiowy.

Jeśli dobrze pamiętam, interwał sondowania NTTP można ustawić na maksymalnie 1024 sekundy. Być może najprostszym rozwiązaniem byłoby uruchomienie ntpdate przy każdym rozruchu, a później co jakiś czas z crontab.

Jeśli twój zegar zaczyna się od losowego czasu przy każdym uruchomieniu, prawdopodobnie i tak nie będziesz w stanie uruchomić ntpd i będziesz musiał najpierw użyć ntpdate. NTTP nie odmawia synchronizacji czasu, jeśli różnica między zegarem a zegarem serwerów jest zbyt duża.

NTP, podobnie jak TCP, ma wbudowaną w protokół głębszą teorię i praktyczne doświadczenie; jeśli zmienisz jego podstawowe parametry, przestanie mieć właściwości synchronizacji, dla których został zaprojektowany.

Jeśli twoje urządzenie jest sporadycznie podłączone, być może stary dobry RDATE będzie ci najlepiej służył. Nie radzi sobie z obrotem zegara, ani uśrednianiem rówieśników, ani nie można go zabezpieczyć przed różnymi subtelnymi hackami, w które człowiek pośrodku mógłby zagrać, gdyby było warto. Po prostu pobiera datę referencyjną ze zdalnego serwera i uderza młotkiem lokalny zegar. Ale robi to, kiedy tego chcesz, a jego zachowanie jest deterministyczne.

Dokładność RDATE jest znacznie gorsza niż zapewnia NTP, nie ufałbym temu dłużej niż ± 1 sekundę, ale jeśli jesteś tylko sporadycznie przywiązany, dokładniejszy czas nie ma znaczenia; w rzeczywistości, zgodnie z teorią względności , może to nawet nie mieć znaczenia.

Aby uwzględnić minpool/, maxpoolnależy uwzględnić, a następnie dodać na serwer w swoim ntp.conf.

Nie jest zalecane, aby zadzierać z demonem NTP (ma wbudowaną matematykę w celu optymalizacji częstotliwości), ale musisz dodać te opcje w następujący sposób:

server time.google.com iburst minpoll 12 maxppol 17
server ntp.ubuntu.com iburst minpoll 12 maxppol 17
server europe.pool.ntp.org iburst minpoll 12 maxppol 17

Tutaj, jeśli ustaw minimalną częstotliwość na 2 ^ 12 sekund, a maksimum na 2 ^ 17 sekund.

Domyślnie dowiedziałem się, że NTP będzie składać żądanie co około minutę. To zdecydowanie za dużo. Tutaj zmniejszyłem częstotliwość z raz na godzinę do raz dziennie (ostrożnie).