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

27.9.2017 21:20 | Přečteno: 3569× | Linuxové drobty | | poslední úprava: 24.10.2017 00:17

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í "intersection 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.

Ještě přidám pár grafů:

Situace je taková. Domácí server je i zálohovací server a jednou za 2 dny prochází připojené notebooky a desktopy a provádí úplné a inkrementální zálohy podle zadanách časů. To co probíhalo a je zachyceno na grafech byla.

1. malá inkrementální záloha jednoho notebooku 19:00 - 19:20
2. úplná záloha druhého notebooku 20:05-22:20 a navazující inkrementální zálohy desktopu a serveru do 22:48
3. inkrementální záloha posledního notebooku 23:00 - 23:15.

Zátěž které měl server je následující.

Průtok dat disky

IOPS

Zatížení disků

 

Zatížení je primárně na zařízení backuppc, což je RAID 10 nad disky a,c,,d,e.

 

Toto zatížení se projeví jako load:

interupty

a v zatížení paměti

díky této zátěži se začnou i posouvat presnosti hodin procesoru systému. Celkový obrázek je:

Jak máme porozumět tomu kmitání ofsetu nahoru a dolů.

Přesnější pohled na odchylku dává:

Tedy v 19:00 hodiny začaly odjíždět do 19:20 a pak se srovnávaly do 20:00. ve 20:00 začaly odjíždět znovu až do 21:00 kde se začaly rovnat, přibližně od 21:40 do 22:40 se držely jakž takž a pak ujely do záporné odchylky s maximem 23:30. Současně pokud se podíváme na chybu, tedy hodnotu kolik si ntpd myslí, že jsou správné hodiny daleko.

je vidět jak chyba stoupá od 19:00 do maxima v 21:30 a pak s prestávkami padá. v nezatíženém systému je odhadovaná chyba hluboce pod milisekundu.

Jak si tohle vysvětlovat? Každé hodiny jsou špatné a ntpd je kompenzuje. Standardně na mém nezatíženém systému je to kolem 20 ppm. Při zatíženém systému (mém systému) se hodiny zpomalí a ntpd to musí vykompenzovat. Kompenzuje to upravami jaderného parametru ppm, tedy kolik jednotek za milion tiků musí přidat nebo ubrat. viz následující graf.

A teď trochu vysvětlování a souvislostí. První záloha trochu pohnula časem ale nic moc. chyba vybehla a ntpd na to zareagoval mírnou vlnkou ppm v čase cca 19:30 která dokázala odchylku trochu stáhnout i když chyba se zatím moc nesnížila. Velká zátěž pohnula s hodinami více a ntpd reagoval celkem pomalu. až v 21 začal masívně navyšovat ppm, aby chybu stáhnul. Nicméně, jak vidět se mu to podařilo brzy cca 21:30 už byly hodiny celkem přesné  Hodnota ppm 24 a něco se asi dá chápat jako správná kompenzace pro můj zatížený systém, nicméně zátěž skončí v 22:40 s malou ještě zátěží po 23. A vysoká hodnota ppm zůstává a hodiny zbytečně zrychlí, odchylka letí do záporna (čas serveru proti kterému se synchronizujeme je pomalejší) a ntpd trvá až do 0:30 než výrazně ppm vrátí nebo přesněji až do 6 a něco než najde znovu správnou hodnotu ppm pro nezatížený systém. což je důvod kmitání odchylky kolem přesného času. Jen poznámka - zajímavost - nesouvisející s časem. když jedou mi ty zálohy, tak rapidně se změní práce s inody.

       

Obrázky

Komentáře

[Bedňa]

Nikdy som neskúmal ako to funguje, proste to funguje, ale som rád, že teraz viem už ako.

Dík.

[Marián Kyral]

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.

[little-drunk-jesus]

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?

[Michal Kubeček]

Za starých dobrých (pre-systemd) časů bývalo zvykem, že to v init scriptech pro xntpd bylo.

[Michal Kubeček]

Máte nějaký důvod, proč nemít v hardwarových hodinách čas v UTC?

[Marián Kyral]

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.

[Dalibor Smolík]

Mrknout se do BIOSu?

[MP]

systemd-timedated to umi. Ale na druhou stranu, neni tak "jemny" jako klasicke ntp, na desktop ok, ale nasazeni na serveru je otazkou.

[lertimir]

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.

[Pavel Píša]

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.

[miros]

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".

[lertimir]

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.

[miros]

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.

[lertimir]

doplnil jsem pár grafů.

[Y.]

Zvazili jste možnost, že hodiny jsou stále stejné přesné, ale mění se přesnost měření, např, pakety dorazí do ntp o něco později, či ntp z nějakého důvodu není vzbuzeno čas, atp? Něco v tomto směru se mi zda na ně RT kernelu pravdepodnejsi než že se začnou rozjíždět hodiny.

[lertimir]

V prvním grafu o čase (pátý graf od konce) je zelená křivka "delay", zachycující zpoždění paketů mezi mým serverem a časovým serverem. Ta křivka se celou dobu nemění (Server je na gigabitu a i silný přenos s notebooku linku nenaplní). Skutečně se hodiny rozjíždějí. Stejnou zkušenost mám i z před více let, kdy na virtuálním serveru byla občas spouštěna zátěž kdy 8 jader jelo cca 2 hodiny na plnž výkon (load asi 8-14) a čas vždy o milisekundy ulítl než ho server dokompenzoval právě pomocí jaderného parametru.

[Vantomas]

V čem vadí, že se rozjede čas o pár jednotek nanejvýš desítky milisekund?

[lertimir]

To asi jak kdy. Já nikde neříkám, jestli to vadí nebo ne. Jen popisuji chování NTP hodin. Některé aplikace na rozcházení času mohou být citlivé (např. NFS), ale milisekundy vadit nebudou a v běžném použití to kritické není. Na druhou stranu pokud by někdo vytvářel přesné hodiny pro organizaci a chtěl od nich vyšší přesnost, je lepší když je rozjede na dedikovném HW (což může být klidně osamocené RPi jedoucí jen hodiny) a ne na systému jehož zatížení se mění. A pokud by potřeboval vyšší přesnost (třeba pro industriální systémy) je tu ještě PTP (a pak jsou také projekty jako White Rabbit)