Portál AbcLinuxu, 17. říjen 2017 07:59

Pár poznámek k řízení času přes NTP

27.9. 21:20 | Přečteno: 1306× | Linuxové drobty | Výběrový blog | poslední úprava: 4.10. 13:49

Nějakou dobu jsem se věnoval naladění ntp na co nejpřesnější doregulaci času. A někdy to tedy moc nejde. Takže bych si sem zanesl pár poznámek. A možná budou i někomu k užitku.

NTP protokol je jeden z nejstarších protokolů na internetu. Funkční je od roku 1985 a ne některých postupech je to znát. Funguje tak, že system pošle UDP paket na synchronizační server, dostane odpověď, kde je napsán čas příjmu výzvy a čas odeslání odpovědi z toho serveru, má zaznamenaný čas vyslání a čas příjmu a z těchto časů spočte jednak zpoždění signálu a jednak svůj posun času.

Tohle provádí na několik nastavených serverů. Z nich pomocí "intesection algorithm" volí ty, které jsou mimo přesný čas a s ostatními pracuje. Zatím algoritmus dobrý.

Ted pár negativních postřehů. Algoritmus finálně vždy zvolí server, ke kterému se blíží (sys_peer). Pokud v nějaké situaci je několik kandidátních serverů a časově od sebe poněkud vzdálených, třeba díky zatížení linky, tak ntp může přepínat mezi servery a čas plave. Není zde žádný algoritmus, kdy klient by se blížil k nejakému váženému průměru času serverů, které byly kvalifikovány jako s OK časem.

Vztah k jednomu serveru: Klient posílá měřící pakety za interval, který považuje na základě vyhodnoceného posunu času za optimální, což je nejdříve 64 vteřin, později se interval prodlužuje až na 1024 vteřin a tam zůstane pokud není nějaká katastrofa. Z každého měření si zaznamenává zpoždění k serveru a vypočítaný offset. Pamatuje si posledních 8 měření a opět (podobně jako v případě serveru) se váže k jedinému z nich a od něj odvozuje posun častu vůči serveru. Preferuje samozřejmě měření, které má menší delay a je novější. A když je nejnovější s větším delay tak samozřejmě záleží o jak moc větší delat. Nicméně to co mne nedávno překvapilo na lokální siti, bylo jak algoritmus nebere v potaz offset. Ze stavu plně časově synchronizovaných strojů se mi při přenosu cca 100G rsyncem po lokální síti rozhodily stroje asi o 20ms. NTP mezitím začal pracovat na synchronizaci. To co bylo ale zajímavé, že v několika případech volil jako hlavní měřící paket ten, co tomu neodpovídal. Na vnitřní sítí mám delay mezi systémy pod 1ms konkrétně první starší měření 0.28 a novější 0.41ms přičemž u prvního měření bylo offset 24,49 a u druhého (pozdějšího) 16,6 (už doladění času probíhalo), přesto perzistentně klient trval na tom, že rozdíl času k tomuto serveru je podle toho prvního (rychlejšího ale s větším offsetem) měření do té doby než proběhlo ještě následující měření. Přičemž je zřejmé, že s jakýmkoliv delay pod 1ms to druhé pozdější měření je přesnější.

Tolik jen pár pozorování. Určitě s NTP nebudu nic dělat, ale když by vám trochu čas plaval, tak to může být i tímto.        

Hodnocení: 100 %

        špatnédobré        

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Nástroje: Začni sledovat (3) ?Zašle upozornění na váš email při vložení nového komentáře. , Tisk

Vložit další komentář

Bedňa avatar 29.9. 00:00 Bedňa | skóre: 33 | blog: Žumpa | Horňany
Rozbalit Rozbalit vše Re: Pár poznámek k řízení času přes NTP
Odpovědět | Sbalit | Link | Blokovat | Admin
Nikdy som neskúmal ako to funguje, proste to funguje, ale som rád, že teraz viem už ako.

Dík.
Pokecajte si s umelou stupiditou na http://www.kernelultras.org/
Marián Kyral avatar 29.9. 08:17 Marián Kyral | skóre: 29 | blog: Sem_Tam | Frýdek-Místek
Rozbalit Rozbalit vše Re: Pár poznámek k řízení času přes NTP
Odpovědět | Sbalit | Link | Blokovat | Admin
Normálně bych to přešel, ale těch chyb je nějak moc ;-)
…oédeslání…
…nění…
…měžení…
…perzisteně…
…že z jakýmkoliv delay…
Jinak já jsem rád, že ntp alespoň nějak funguje. Bohužel v některých případech ani ntp nepomůže. Třeba když zapnu počítač po delší době a mezitím došlo k posunu času na letní/zimní. Ntp v tomto případě nezafunguje - že prý to je moc velký posun - a musím to řešit ručně. Je to sice jen dvakrát ročně, ale uvítal bych, pokud bych ani tohle řešit nemusel.
29.9. 08:32 little-drunk-jesus | skóre: 12
Rozbalit Rozbalit vše Re: Pár poznámek k řízení času přes NTP
Nestacilo by do ntp systemd service pridat do ExecStartPre= jednorazovou synchronizaci pomoci ntpdate? Takze by se ti cas syncnul skokove pred tim, nez by ntp demon nabehl?
29.9. 10:18 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Pár poznámek k řízení času přes NTP
Za starých dobrých (pre-systemd) časů bývalo zvykem, že to v init scriptech pro xntpd bylo.
29.9. 10:17 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Pár poznámek k řízení času přes NTP
Máte nějaký důvod, proč nemít v hardwarových hodinách čas v UTC?
Marián Kyral avatar 30.9. 18:50 Marián Kyral | skóre: 29 | blog: Sem_Tam | Frýdek-Místek
Rozbalit Rozbalit vše Re: Pár poznámek k řízení času přes NTP
Abych pravdu řekl, vůbec netuším, jak tam ten čas mám uložený. Je to ještě nějaký AMD Athlon. A nejsem si jist, jestli aktuální MB ještě zažil dual boot s windows XP. Musím zkontrolovat.
1.10. 11:44 MP
Rozbalit Rozbalit vše Re: Pár poznámek k řízení času přes NTP
systemd-timedated to umi. Ale na druhou stranu, neni tak "jemny" jako klasicke ntp, na desktop ok, ale nasazeni na serveru je otazkou.
4.10. 14:02 lertimir | skóre: 60 | blog: Par_slov
Rozbalit Rozbalit vše Re: Pár poznámek k řízení času přes NTP
Diky za poznámky, někdy to nevidím. K synchronizaci dvě poznámky. Jednak všechny systémy důsledně jedu v UTC a lokální hodiny jsou součástí lokálního nastavení. A za druhé buď periodicky a nebo při vypínání systému provádím hwclock -systohc, které zapíše systémový čas do hw hodin a pak při dalším startu to není nijak moc daleko.
29.9. 16:48 Pavel Píša | skóre: 11
Rozbalit Rozbalit vše Re: Pár poznámek k řízení času přes NTP
Odpovědět | Sbalit | Link | Blokovat | Admin

V mnoha současných distribucích je jako základ pro NTP použitá varianta daemona chrony. Ten používá následující konfigurační soubor /etc/chrony/chrony.conf. V něm je možné povolit, že je na začátku přípustné provést korekci mimo běžné limity.

makestep 1 -1

První hodnota říká, při jak velkém rozdílu již nedojíždět k správnému času plynule, u nás, jakmile je rozdíl větší než 1 sekunda. Druhý parametr pak omezuje do kolika výměn po startu je ještě přechod na srovnání času skokem přípustný. U studentských stanic v lokální síti to moc neřešíme a záporná hodnota (-1) pak specifikuje, že kdykoliv dojde k velkému odstupu od serveru, tak se natvrdo stanice sesynchronizují. Pro server nebo prostředí s certifikáty a bezpečností to asi není ideální, ale i když bootujeme naše prostředí v laboratořích, kde jiné katedry používají Windows, tak je od problémů s časem pokoj.

Volby rtconutc a rtcsync máme zakomentované, aby nebyly při nutnosti soužití s jinými systémy potíže a GNU/Linux pak na stanicích RTC ignoruje.

Více ke zkušenostem může říct správce naší infrastruktury - Aleš Kapica.

29.9. 19:16 miros
Rozbalit Rozbalit vše Re: Pár poznámek k řízení času přes NTP
Odpovědět | Sbalit | Link | Blokovat | Admin
Není zde žádný algoritmus, kdy klient by se blížil k nejakému váženému průměru času serverů, které byly kvalifikovány jako s OK časem.
Takový algoritmus v ntpd je, dokonce je i ve specifikaci NTP jako "combining algorithm". Offsety serverů, které ve výpisu ntpq -pn mají značku + jsou zkombinovány s tím co má *. Jako váha se bere "root distance".
4.10. 13:46 lertimir | skóre: 60 | blog: Par_slov
Rozbalit Rozbalit vše Re: Pár poznámek k řízení času přes NTP
Ano je. Ale v RFC 1305 je psáno:
Appendix F describes an optional algorithm to improve accuracy by combining the time offsets of a number of clocks.
Takže díky "optional" netuším, jak to je u konkrétních daemonů. U standardního ntpd jsem nenašel žádnou volbu, kterou bych tento volitelný algoritmus zapnul nebo vypnul. A osobní pocit z pozorování chování hodin bylo: "Přibližuji se k sys-peer serveru (s hvězdičkou v ntpq -p)." Ne že se přibližuje k nějakému váženému průměru.
5.10. 21:36 miros
Rozbalit Rozbalit vše Re: Pár poznámek k řízení času přes NTP
RFC 1305 je už hodně staré a bylo nahrazeno RFC 5905. ntpd je referenční implementace, podle které se ty RFC psaly, takže obsahuje všechny popsané algoritmy.

Minimální a maximální počet zkombinovaných serverů se dá nastavit přes tos minclock a tos maxclock.

Když si vypíšete asociace přes ntpq -c as a pak proměnné všech serverů přes ntpq -c 'rv $ID', jakou root dispersion a delay má ten server s hvězdičkou oproti těm s pluskem? Možná je mnohem blíž a tak má jeho offset mnohem větší váhu.

Založit nové vláknoNahoru

ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.