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

[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)