Dotaz: Home server - rozchází se čas

[pavell]

Ahoj, pozoruji problém na svém domácím serveru (Debian Jessie). Synchronizuji oproti tik.cesnet.cz. Vůbec netuším, v čem by mohl být problém. Poradíte?

Nov 19 10:08:57 server ntpd[17810]: adjusting local clock by -6.918688s
Nov 19 10:10:35 server ntpd[17810]: adjusting local clock by -6.988157s
Nov 19 10:14:17 server ntpd[17810]: adjusting local clock by -6.942177s
Nov 19 10:16:29 server ntpd[17810]: adjusting local clock by -6.959951s
Nov 19 10:19:09 server ntpd[17810]: adjusting local clock by -6.945702s
Nov 19 10:21:16 server ntpd[17810]: adjusting local clock by -6.981157s
Nov 19 10:24:19 server ntpd[17810]: adjusting local clock by -6.938779s
Nov 19 10:25:51 server ntpd[17810]: adjusting local clock by -6.985607s
Nov 19 10:29:03 server ntpd[17810]: adjusting local clock by -6.938420s
Nov 19 10:30:39 server ntpd[17810]: adjusting local clock by -7.020783s
Nov 19 10:34:52 server ntpd[17810]: adjusting local clock by -7.007239s
Nov 19 10:38:30 server ntpd[17810]: adjusting local clock by -6.930984s
Nov 19 10:39:35 server ntpd[17810]: adjusting local clock by -6.946096s
Nov 19 10:41:09 server ntpd[17810]: adjusting local clock by -7.028710s
Nov 19 10:45:27 server ntpd[17810]: adjusting local clock by -7.000215s
Nov 19 10:48:42 server ntpd[17810]: adjusting local clock by -6.952083s
Nov 19 10:50:22 server ntpd[17810]: adjusting local clock by -6.968548s
Nov 19 10:52:29 server ntpd[17810]: adjusting local clock by -6.987939s
Nov 19 10:55:07 server ntpd[17810]: adjusting local clock by -7.006981s
Nov 19 10:58:19 server ntpd[17810]: adjusting local clock by -7.007941s
Nov 19 11:01:25 server ntpd[17810]: adjusting local clock by -7.013244s
Nov 19 11:04:36 server ntpd[17810]: adjusting local clock by -6.981912s
Nov 19 11:06:47 server ntpd[17810]: adjusting local clock by -6.998489s
Nov 19 11:09:28 server ntpd[17810]: adjusting local clock by -7.034400s
Nov 19 11:13:07 server ntpd[17810]: adjusting local clock by -6.972908s
Nov 19 11:14:43 server ntpd[17810]: adjusting local clock by -7.037462s
Nov 19 11:18:29 server ntpd[17810]: adjusting local clock by -6.991550s
Nov 19 11:20:33 server ntpd[17810]: adjusting local clock by -7.058705s
Nov 19 11:24:42 server ntpd[17810]: adjusting local clock by -7.061525s
Nov 19 11:28:57 server ntpd[17810]: adjusting local clock by -6.949787s
Nov 19 11:29:27 server ntpd[17810]: adjusting local clock by -7.034391s
Nov 19 11:32:35 server ntpd[17810]: adjusting local clock by -7.068075s
Nov 19 11:36:50 server ntpd[17810]: adjusting local clock by -7.036849s
Nov 19 11:40:02 server ntpd[17810]: adjusting local clock by -7.057115s

---

---

Odpovědi

[chrono]

Nastav presný čas napr. pomocou ntpdate (pretože odchýlka času je aktuálne príliš veľká).

[JMP]

pokud nejste součástí cesnetu, tak používejte následující: http://www.pool.ntp.org/zone/cz

klasické ntpd není moc odolné na velké časové úchylky - chrony mi v tomto ohledu přijde výrazně lepší...

[pavell]

Diky Vám oběma, nyní používám cz.pool.ntp.org, nicméně problém to nevyřešilo.

Dvě spuštění ntpdate ihned po sobě a hned odchylka 0.3s.

server# ntpdate 0.cz.pool.ntp.org ; ntpdate 0.cz.pool.ntp.org
19 Nov 16:28:33 ntpdate[12952]: adjust time server 91.216.168.42 offset -0.379121 sec
19 Nov 16:28:41 ntpdate[12954]: adjust time server 91.216.168.42 offset -0.379329 sec

Na mojí workstation je odchylka řádově nižší:

worstation# ntpdate 0.cz.pool.ntp.org ; ntpdate 0.cz.pool.ntp.org
19 Nov 16:28:47 ntpdate[2897]: adjust time server 81.0.235.220 offset 0.000233 sec
19 Nov 16:28:54 ntpdate[2898]: adjust time server 81.0.235.220 offset -0.000166 sec

Nemůže jít o hw problém na serveru? Přeci jen běží 24/7, je to Mini-ITX deska, která na to není stavěná. Napadá mě baterie na desce?

[pavlix]

Nějak nechápu co řešíš?

Nech ntpd server běžet a budeš mít čas OK.

Jinak fakt 0.3s je na domácí server strašná odchylka........

Dále baterka s tím nemá nic společného, baterka napájí HW hodiny z kterých OS bere čas pouze při spuštění.

Za chodu se bere čas z SW hodin v OS, a samozřejmě rozcházet se můžou jsou to SW hodiny takže pokud je server přetížen a nestihne se IRQ pro aktualizaci hodin....( Nech běžet ntpd ten ty hodiny bude dorovnavat. A nebo si postav atomové hodiny.... ) )

Taky záleží s jakou volbou je kernel přeložen...RT kernely atd....

[Peter Golis]

Môže ísť aj o problém ACPI. Ak kernel nevie dorovnať čas pri znížení frekvencie CPU, tak to podobne blbne. Alebo ak je na doske slabá baterka, tak HW hodiny blbnú.

Ale odchýlka skoro 0.4s za 10 minút, to je skoro minúta denne pri výpadku internetu. To môže spôsobiť problémy pri nahrávaní TV programov aj keď televízie majú schválne väčšie deviácie. Ak je to neprekonateľný problém, tak si nacvakni GPS ako zdroj resného času.

PS: Už som mal aj väčšie úchylky v HW hodinkách. Po výmene baterky sa to v pohode zrovnalo. Ale ten stroj mal vtedy cez 5 rokov a už zomrel.

[Petr Šobáň]

Baterka na to nemá vliv - pokud teda server nevypíná, samozřejmě pokud je baterka slabá můžou HW hodiny blbnout.

Takže pokud server vypíná tak výměna baterky může pomoci.

Pokud server nevypíná tak to baterkou není.

PS si porovnej jaký čas máš v HW hodinách s SW hodinama.

petr@notebook:~$ sudo hwclock 
[sudo] heslo pro petr: 
So 19. listopad 2016, 18:09:38 CET  .921309 seconds
petr@notebook:~$ sudo hwclock -r
So 19. listopad 2016, 18:09:54 CET  .624463 seconds
petr@notebook:~$ sudo hwclock -r
So 19. listopad 2016, 18:09:59 CET  .389854 seconds
petr@notebook:~$ sudo hwclock -r
So 19. listopad 2016, 18:10:01 CET  .124451 seconds
petr@notebook:~$ sudo hwclock -r
So 19. listopad 2016, 18:10:02 CET  .999410 seconds
petr@notebook:~$ sudo hwclock -r
So 19. listopad 2016, 18:10:05 CET  .015004 seconds
petr@notebook:~$ sudo hwclock -r
So 19. listopad 2016, 18:10:06 CET  .917053 seconds
petr@notebook:~$ sudo hwclock -r
So 19. listopad 2016, 18:10:08 CET  .452584 seconds
petr@notebook:~$ sudo hwclock -r
So 19. listopad 2016, 18:10:09 CET  .921391 seconds
petr@notebook:~$ sudo hwclock -r
So 19. listopad 2016, 18:10:11 CET  .327462 seconds
petr@notebook:~$ 

[Peter Golis]

Baterka na to nemá vliv - pokud teda server nevypíná, samozřejmě pokud je baterka slabá můžou HW hodiny blbnout.

To mi pripomenulo tvrdenie: Každá poučka potrebuje výnimku.

[Petr Šobáň]

U serveru nepředpokládám vypínání, ale samozřejmě nevíme jak ho doma provozuje.....

[pavell]

Vzdyt jsem psal, bezi 24/7, ale stehovali jsme se a behem toho byl par dnu vypnuty. Az nyni pozoruji uvedene problemy, ale nevylucuju, ze tam byly uz predtim, jen jsem si jich treba nevsiml.

[Peter Golis]

Vek tej baterky je rádovo v rokoch? Nie je použitá príliš stará generácia jadra na príliš nové železo? Má použitá verzia UEFI Firmware reportované problémy?

Otázky, samé otázky.

[Petr Šobáň]

Baterka má vydržet 10let skladování.

Na MB vydrží většinou kolem 5let záleží na odběru.

[Peter Golis]

Na MB vydrží většinou kolem 5let záleží na odběru.

To mi pripomenulo tvrdenie: Každá poučka potrebuje výnimku.
Nevyučuješ náhodou na základnej škole že tak často používaš poučky ktoré potrebujú výnimky?

[Filip Jirsák]

Baterka na to u běžícího systému opravdu nemá vliv. Baterka slouží pro udržení času v obvodu RTC (tedy hw hodin) i při vypnutím počítači. Při startu si odsud systém čas načte, dále používá jen sw hodiny a při vypnutí obvykle nějaký skript zase aktuální sw čas uloží do RTC. Při běhu počítače tedy baterka nemá na hodiny žádný vliv, protože se RTC vůbec nepoužívá.

[Peter Golis]

Sklamem ťa, zažil som ako slabá baterka rozhodila hodiny. Ale to som už spomínal. Len doplním že kôli slabej (ale ešte vtedy nevybitej) baterke mi na tom nefungovala kalibrácia SW časovača pri štarte. RTC sa tak degradovalo na TC.

[Filip Jirsák]

Ono je těžké pochopit, co se vám vlastně stalo, když neustále mícháte hardwarové a softwarové hodiny. Už už to vypadá, že chybný chod hw hodin při startu ovlivnil špatné počítání sw hodin, a pak do toho zase zamícháte RTC, tedy hardwarové hodiny, a jsme tam, kde jsme byli. Jinak ntpd právě opraví i to, když jdou softwarové hodiny rychleji nebo pomaleji – sleduje rozdíly a sw hodiny zrychlí nebo zpomalí. Kalibrace sw časovače při startu podle RTC se mi moc nezdá, protože sw časovač má o několik řádů větší rozlišení oproti RTC.

[Peter Golis]

Ja viem, že je ťažké pochopiť že baterka sa týka HW hodín. Tak isto je ťažké pochopiť že stupnička na nekalibrovanom meradle, alebo na meradle ktoré je po záruke už nemusí byť presná ani ako digitálky z blšáku. Spoliehať sa na to že tých viac dielikov (väčšie rozlíšenie) naozaj znamená aj väčšiu presnosť mi pripomína klasický výrok: Viac prúžkov, viac Abiddas.

Inak, NTP nič neopravuje, NTP len zrovná aktuálnu odchýlku.

Ale, to je jedno. Zadávateľ témy len povedal že má v logu pri synchronizácii času informáciu o odchýlke. A o železe, baterke alebo pripojení neprezradil nič. Proste, rozoberá sa tu virtuálny problém ktorý tu trápi len poučkárov čo do jednej vety zakomponujú výnimku na tú istú jednu vetu. Alebo takých, čo s myslia že všetky meracie komponenty fungujú dostatočne presne bez kalibrácie.

PS: Je v kľude možné aj to, že si ten čas zrovnáva cez niekoľko skokov na WiFi, detaily už nemusím rozoberať. Inteligentný človek pochopí.

[Filip Jirsák]

Ja viem, že je ťažké pochopiť že baterka sa týka HW hodín.

Není to těžké pochopit. V této diskusi to s jedinou výjimkou chápou všichni – pouze z vašich komentářů to vypadá, že to nechápete, když pořád u serveru běžícího nonstop řešíte baterku. Ale možná to jenom nešťastně formulujete.

A o železe, baterke alebo pripojení neprezradil nič.

Přičemž baterka ani železo na to nemají vliv, jak se vám tu několik lidí snaží vysvětlit. Protože železo i baterka jsou hw hodiny, které se naposledy použily při startu počítače, a od té doby už se čas řídí čistě jen softwarovými hodinami. Které má ntp-client a ntpd postupně srovnat tak, aby běžely přesně, bez ohledu na to, jak běžely na začátku.

Inak, NTP nič neopravuje, NTP len zrovná aktuálnu odchýlku.

Já jsem nepsal o protokolu NTP – ten navíc ani nic nerovná, pouze poskytne informaci o správném času. Psal jsem o démonu ntpd, který se snaží udržovat na počítači přesný čas. Tedy zjistí si rozdíl přes protokol NTP, ale pak se snaží zjistit systematickou odchylku softwarových hodin a srovnat jí (aby odchylka od přesného času nebyla „zubatá“ – že se čas sesynchronizuje podle NTP, pak se rozjíždí, znovu se sesycnhronizuje s NTP atd.), případné malé odchylky, které se projeví i po zkalibrování sw hodin, odstraňuje krátkodobým zrychlením nebo zpomalením sw hodin (aby nedocházelo ke skokovým změnám času nebo dokonce cestování do minulosti), teprve větší odchylky srovná skokově, a v případě ještě větší odchylky odmítne čas synchronizovat úplně a nechá řešení toho problému na správci, což je oblíbená past na správce (protože předpokládá, že to může způsobit nějaké problémy a že velká odchylka od přesného času znamená, že je něco špatně). Proto se doporučuje při startu počítače srovnat hodiny jednorázově ntp-clientem a teprve pak spustit ntpd.

[Peter Golis]

Aha, už som to pochopil. Vy sa mi snažíte vysvetliť, že moje spomienky keď sa mi na počítači rozchádzal čas kvôli slabej baterke sú blbosť. A tak isto sa mi snažíte vysvetliť že moje spomienky o tom, že sa mi prestal rozchádzať po výmene baterky sú rovnaká blbosť. Podľa vás viete viac o tom čo sa stalo nielen mne, aj keď ste s takým niečim nikdy neprišiel do styku.

No, vaše presvedčenie je založené na nepochopení rozdielu významu slov solution a workaround. Proste ste presvedčený že ntpd je riešenie ktoré napraví hodinky a zrovnáva odchýľky. Bez ohľadu na to, že len zahladzuje dané odchýľky vzniknuté rozhodenou kalibráciou a neuvedomujete si že akýkoľvek mechanizmus slúžiaci na meranie je treba kalibrovať. No, nebol by som si istý či by som sa mal odvahu spoľahnúť na vašu prácu. Cól sem, cól tam. Šak ntpd doťáhne. Zvyšok ide presnejšie jak céziové hodiny, šak je to na veľa digitálnych čísel.

PS: To, že hovoríte za seba v množnom čísle som si už všimol. A viem čo to znamená, a tak som to akceptoval.

[Filip Jirsák]

Zase jste to pochopil špatně. Já se vám snažím vysvětlit, že když počítač s Linuxem běží, nemají na jeho čas hardwarové hodiny žádný vliv. Na některých zařízeních dokonce ani žádné hardwarové hodiny reálného času nejsou, přesto na nich běží Linux a v něm může běžet přesný čas. Jaké máte nebo nemáte vzpomínky neřeším, pouze se podivuji nad tím, že ve svých příspěvcích neustále mícháte dohromady hardwarové hodiny a softwarové hodiny, přitom je to každé něco jiného a čas v běžícím Linuxu je řízen softwarovými hodinami. Jediný okamžik, kdy do toho hardwarové hodiny mohou zasáhnout, je start systému, kdy je možné volitelně softwarové hodiny seřídit podle hardwarových hodin, abyste měl jakýs takýs čas dřív, než se spustí nějaká služba, která je schopná poskytovat přesnější čas.

Odchylky v softwarovém času nejsou způsobené rozhozenou kalibrací (to právě ntpd dokáže srovnat), ale tím, že použitý čítač má jen omezenou přesnost a jeho primární účel není udržování přesného času, takže se občas může stát, že se nějaký ten tik propásne. Softwarové hodiny mají řádově větší frekvenci, než hardwarové, takže nevím, co byste na softwarových hodinách chtěl podle těch hardwarových kalibrovat. A i kdybyste si je tak kalibroval, tady se bavíme o běžícím ntpd, které softwarové hodiny kalibruje průběžně podle údajů, které dostává přes NTP protokol. Takže případná chyba by se projevovala jenom pár minut po startu, než by to ntpd srovnalo.

Pokud nechápete rozdíl mezi softwarovými hodinami a nechápete, jak funguje služba ntpd (nastudovat si to můžete třeba zde: Clock Discipline Algorithm), asi těžko tady něco poradíte. Tazatel má problém se synchronizací softwarových hodin pomocí ntpd. Aby se softwarové hodiny za minutu rozjely o půl sekundy, to je opravdu hodně. Napadají mne tři možné důvody:

• Nějaká podivná platforma, na které se často mění frekvence čítače, který Linux používá pro softwarové hodiny, a Linux ty změny nedokáže podchytit. To mi připadá nepravděpodobné.
• Síť s velkými rozdíly v latenci, třeba nějaká zarušená WiFi. Problém by pak nebyl v samotných softwarových hodinách, ale v tom, že ntpd nedokáže NTP protokolem získat dostatečně přesný čas. V takovém případě by pomohlo jen použít jiný zdroj přesného času, nebo se smířit s tím, že čas nebude zas až tak přesný a synchronizovat třeba jednou denně skokově přes ntp-client.
• ntpd dokáže správně získat přesný čas, ale nedokáže ho správně vnutit kernelu. To se mi jeví jako nejpravděpodobnější, protože ty odchylky jsou v čase hodně podobné – tj. zdá se, že ntpd se sice pokusí provést korekci, ale ta není úspěšná, takže další odchylka je podobná té předchozí. Zkusil bych zvýšit úroveň výpisu ntpd, mělo by snad někde vypsat, která operace se nepovedla. Zaměřil bych se na to, zda tam není nějaké nestandardní jádro nebo stará verze ntpd nebo jádra. V běžných distribucích by mělo být aktuální ntpd sladěné s aktuálním jádrem tak, aby spolu fungovaly správně.

[pavlix]

ntpd dokáže správně získat přesný čas, ale nedokáže ho správně vnutit kernelu. To se mi jeví jako nejpravděpodobnější, protože ty odchylky jsou v čase hodně podobné – tj. zdá se, že ntpd se sice pokusí provést korekci, ale ta není úspěšná, takže další odchylka je podobná té předchozí. Zkusil bych zvýšit úroveň výpisu ntpd, mělo by snad někde vypsat, která operace se nepovedla. Zaměřil bych se na to, zda tam není nějaké nestandardní jádro nebo stará verze ntpd nebo jádra. V běžných distribucích by mělo být aktuální ntpd sladěné s aktuálním jádrem tak, aby spolu fungovaly správně.

Ahoj, bylo to zřejmě tak, jak popisuješ. Vyměnil jsem OpenNTPd za NTPd a problém zázračně vymizel. I tak díky všem, dozvěděl jsem se i něco nového.

Pozn: kernel je distribuční: Linux server 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64 GNU/Linux

[Petr Šobáň]

Nějak nechápu proč do toho taháte HW hodiny, ty mají na to vliv pouze při startu kdy si OS načte čas aby SW hodiny nezačínaly v roku 1970 a nebyl to takový skok.

Já na svém raspi HW hodiny nemám a čas mám OK.

Viz:

pi@radio(ro):~$ date
Ne lis 20 14:55:59 CET 2016
pi@radio(ro):~$ ls -l /tmp
celkem 52
-rw-r--r-- 1 root root      11 led  1  1970 asound.state.lock
drwxr-xr-x 3 root root     120 lis 20 14:56 dhcpcd
-rw-r--r-- 1 root root       4 led  1  1970 dhcpcd.pid
srw-rw---- 1 root root       0 led  1  1970 dhcpcd.sock
srw-rw-rw- 1 root root       0 led  1  1970 dhcpcd.unpriv.sock
drwxr-xr-x 2 root root      60 led  1  1970 dnsmasq
-rw-r--r-- 1 pi   pi     12976 lis 20 14:52 d589a48862398ed80a3d6066f4f56f4c-le32d8.cache-4
drwxr-xr-x 2 root root      80 led  1  1970 lirc
-rw-r--r-- 1 root root       3 led  1  1970 ntpd.pid
-rw-r--r-- 1 root root     137 led  1  1970 resolvconf_resolvers.conf
drwxr-xr-x 2 root root      40 led  1  1970 sshd
-rw-r--r-- 1 root root       4 led  1  1970 sshd.pid
-rw-r--r-- 1 root root       4 led  1  1970 syslogd.pid
drwxr-x--- 2 root netdev    60 led  1  1970 wpa_supplicant
-rw-r--r-- 1 pi   pi       112 lis 20 14:52 3830d5c3ddfd5cd38a049b759396e72e-le32d8.cache-4
-rw-r--r-- 1 pi   pi        72 lis 20 14:52 4c599c202bc5c08e2d34565a40eac3b2-le32d8.cache-4
-rw-r--r-- 1 pi   pi       128 lis 20 14:52 7ef2298fde41cc6eeb7af42e48b7d293-le32d8.cache-4
pi@radio(ro):~$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+herbrand.noumic 193.190.230.66   2 u   32   64    7   54.723   -3.962   2.586
*lx.ujf.cas.cz   147.231.100.11   2 u   23   64   17   35.856   -2.784   1.882
+2a02:8300:8000: 116.49.102.213   2 u   22   64   17   37.611   -2.068   1.595
-xm02.qls.cz     147.231.2.6      2 u   58   64   17   50.835   -9.951   9.445
pi@radio(ro):~$ 

To že tam hodiny nebyly nastavené je z výpisu tmp kde je datum 1.1.1970 než se hodiny pomocí ntpd serveru nastavily na správný čas.

[Peter Golis]

To ja viem že to nechápete, to ste už hovoril. Ale opis okolností a vyriešenie môjho starého problému ktorý je identický z týmto tu už aj napriek tomu nemá zmysel rozoberať. Zbytočne by som sa opakoval.

Pôvodná otázka bola: v čom by mohol byť problém keď sa rozchádza čas v počítači s realitou (aj keď je následne zrovnávaný cez NTP). Vaše reakcie sú v zmysle že to nie je možné lebo "náhodný argument". WoW.

[Petr Šobáň]

A odpověď byla už v prvním mém příspěvku že za to HW hodiny nemůžou a to se i potvrdilo že nějaká nekompatibilita s SW s kernelem, výměnou NTP SW se to vyřešilo.

[lertimir]

A ani to jinak být nemohlo. BUď by byly SW hodiny natolik špatné, že sychronizovat nešly, nebo (což z těch výpisů vypadalo. jádro na pokyny ntpd nereagovalo.)

[Filip Jirsák]

Ne, popis vašeho starého problému nebyl identický, vy jste popisoval úplně jiný problém. Ve vašem popisu nebylo ani slovo o NTP a psal jste o tom, že vám šly špatně hardwarové hodiny. Tazatel řešil problém s NTP a šly mu špatně softwarové hodiny. Navíc vy jste neustále míchal dohromady váš popis problému a vaši interpretaci, přičemž část vaší interpretace byla evidentně chybná. Takže se dalo těžko zjistit, čemu z toho zbytku se dá věřit. Navíc pokud se nepletu, dříve (v dobách AT zdrojů) byl obvod hodin reálného času opravdu napájen baterkou, protože při vypnutém počítači bylo kompletně odpojeno napájení. Pak přišly ATX zdroje, které stand-by větev napájely neustále, a z této větvě začal být napájen i obvod hodin reálného času. Baterka tedy slouží jenom jako záloha pro případ, kdy není napájena ani stand-by větev.

Pôvodná otázka bola: v čom by mohol byť problém keď sa rozchádza čas v počítači s realitou (aj keď je následne zrovnávaný cez NTP). Vaše reakcie sú v zmysle že to nie je možné lebo "náhodný argument".

Ne, otázka byla, v čem je problém, když se nedaří pomocí NTP synchronizovat softwarové hodiny. Vy jste do toho neustále motal hardwarové hodiny a nenechal jste si vysvětlit, že hardwarové hodiny jsou něco jiného, než softwarové. Vaši zkušenost nikdo nezpochybňoval, problém byl pouze ve vaší interpretaci.

[Peter Golis]

Popis problému bol "problém nastavenia hodín".

[pavell]

Tak po tom, co jsem přepnul na cz.pool.ntp.org tak syslog vypadá takto:

Nov 19 16:19:33 server ntpd[12691]: ntp engine ready
Nov 19 16:19:54 server ntpd[12691]: peer 94.124.107.190 now valid
Nov 19 16:19:56 server ntpd[12691]: peer 80.79.25.111 now valid
Nov 19 16:19:56 server ntpd[12691]: peer 46.167.244.222 now valid
Nov 19 16:19:58 server ntpd[12691]: peer 81.2.254.224 now valid
Nov 19 16:20:54 server ntpd[12690]: adjusting local clock by -0.783751s
Nov 19 16:23:31 server ntpd[12690]: adjusting local clock by -0.364209s
Nov 19 16:26:42 server ntpd[12690]: adjusting local clock by -0.366747s
Nov 19 16:27:31 server ntpd[12691]: peer 46.167.244.222 now invalid
Nov 19 16:27:37 server ntpd[12690]: adjusting local clock by -0.341809s
Nov 19 16:28:39 server ntpd[12690]: adjusting local clock by -0.434803s
Nov 19 16:32:56 server ntpd[12690]: adjusting local clock by -0.287299s
Nov 19 16:35:36 server ntpd[12690]: adjusting local clock by -0.310647s
Nov 19 16:37:10 server ntpd[12690]: adjusting local clock by -0.459971s
Nov 19 16:38:42 server ntpd[12690]: adjusting local clock by -0.473243s
Nov 19 16:41:51 server ntpd[12690]: adjusting local clock by -0.383809s
Nov 19 16:42:56 server ntpd[12690]: adjusting local clock by -0.385968s
Nov 19 16:47:10 server ntpd[12690]: adjusting local clock by -0.290378s
Nov 19 16:47:40 server ntpd[12690]: adjusting local clock by -0.316128s
Nov 19 16:49:15 server ntpd[12690]: adjusting local clock by -0.327180s
Nov 19 16:52:26 server ntpd[12690]: adjusting local clock by -0.358129s
Nov 19 16:55:09 server ntpd[12690]: adjusting local clock by -0.283413s
Nov 19 16:56:45 server ntpd[12690]: adjusting local clock by -0.315908s
Nov 19 17:00:22 server ntpd[12690]: adjusting local clock by -0.375862s
Nov 19 17:04:07 server ntpd[12690]: adjusting local clock by -0.308793s
Nov 19 17:05:11 server ntpd[12690]: adjusting local clock by -0.394132s
Nov 19 17:09:29 server ntpd[12690]: adjusting local clock by -0.311061s
Nov 19 17:10:35 server ntpd[12690]: adjusting local clock by -0.356446s
Nov 19 17:11:07 server ntpd[12690]: adjusting local clock by -0.364804s
Nov 19 17:14:21 server ntpd[12690]: adjusting local clock by -0.298772s
Nov 19 17:14:21 server ntpd[12691]: reply from 94.124.107.190: negative delay -0.013978s, next query 3096s
Nov 19 17:18:31 server ntpd[12691]: peer 89.221.208.61 now valid
Nov 19 18:05:58 server ntpd[12690]: adjusting local clock by -1.670545s
Nov 19 18:05:58 server ntpd[12691]: clock is now synced
Nov 19 18:08:03 server ntpd[12690]: adjusting local clock by -1.608044s
Nov 19 18:08:03 server ntpd[12691]: clock is now unsynced
Nov 19 18:09:06 server ntpd[12690]: adjusting local clock by -1.636059s
Nov 19 18:13:28 server ntpd[12690]: adjusting local clock by -1.678649s
Nov 19 18:17:46 server ntpd[12690]: adjusting local clock by -1.686265s
Nov 19 18:22:00 server ntpd[12690]: adjusting local clock by -1.647199s
Nov 19 18:24:11 server ntpd[12690]: adjusting local clock by -1.653045s
Nov 19 18:28:22 server ntpd[12690]: adjusting local clock by -1.639692s
Nov 19 18:29:57 server ntpd[12690]: adjusting local clock by -1.680156s
Nov 19 18:32:40 server ntpd[12690]: adjusting local clock by -1.634855s
Nov 19 18:34:45 server ntpd[12690]: adjusting local clock by -1.684379s
Nov 19 18:34:45 server ntpd[12691]: reply from 89.221.208.61: negative delay -0.100812s, next query 3147s
Nov 19 18:45:18 server ntpd[12691]: peer 80.79.25.111 now invalid
Nov 19 18:56:30 server ntpd[12691]: peer 81.2.254.224 now invalid
Nov 19 18:56:30 server ntpd[12691]: 2 out of 4 peers valid
Nov 19 18:56:30 server ntpd[12691]: bad peer 0.cz.pool.ntp.org (78.108.145.1)
Nov 19 18:56:30 server ntpd[12691]: bad peer 1.cz.pool.ntp.org (147.251.48.140)
Nov 19 19:27:13 server ntpd[12690]: adjusting local clock by -0.881156s
Nov 19 19:27:45 server ntpd[12690]: adjusting local clock by -0.898808s
Nov 19 19:29:51 server ntpd[12690]: adjusting local clock by -1.699764s
Nov 19 19:33:37 server ntpd[12690]: adjusting local clock by -1.683850s
Nov 19 19:34:08 server ntpd[12690]: adjusting local clock by -1.733996s

[lertimir]

zkoumal bych situaci pomocí ntpdc a ntpq. To že ntpd provede explicitní adjusting je spíše známka toho, že není schopen poslat do jádra informace o ppm o kolik se mají mikroadjustovat hodiny. Např to, že adjustace proběhla v 16:38:42 o 0,47 a předtím v 16:37:10 adjustace o 0,45 je absurdní. fakticky za 1:32 minuty se žádné normální hodiny nemohou rozejít o skoro půl vteřiny. to by byla chyba více než 0,5%. (mezi 17:10:35 a 17:11:07 je to ještě horší) Podle mne buď jsou hodiny zcela chybně nebo se požadavek serveru nepřenese do jádra. Co dostane ntpdc -c příkaz, kde příkaz je kerninfo, sysinfo, iostats, sysstats a timerstats

[Peter Golis]

K tomu pridám príkaz hwclock -c nech sa vylúči možnosť že sa len jedná o falošný poplach spôsobený prvotným vytiahnutím času kde nie je známe trvanie získania času.

[Radovan Garabik]

Mohlo by pomôcť zmeniť clocksource v /sys/devices/system/clocksource/clocksource0/current_clocksource - na jednom počítači som to zmenil z tsc na hpet a upravilo to drift z niekoľkých sekúnd denne na desatinu sekundy.

Keď je drift systematický a stabilný, môže pomôcť adjtimex.

[Filip Jirsák]

Keď je drift systematický a stabilný

…tak to zvládne i ntpd. Adjtimex by dávalo smysl použít jedině v případě, kdy nemůžete synchronizovat čas přes NTP ani žádným jiným způsobem.

[pavell]

Vyřešeno, dík všem!