Dotaz: NTP

[Jarda]

Ahoj vsem. Mame v podnikove siti NTP server Stratum 2 a v jine lokalite Stratum 3. Bohuzel se nahodile stane, ze se cas "rozjede" o cca 0,1sekundy. Problem to sice neni vazny, ale na tomto casu je zavislych vice aplikaci, ktere pak vyhazuji chybovost. To ted ale neni dulezite. Chapu, ze by mezi nimi mohlo dojit k zakolisani site, ale i kdyby nemely kratkodobou konektivitu, preci se najdou nerozjede cas o 2-3 rady. Obe stanice bezi na Sol9/SPARC

Vypis loopstats:

57340 20260.771 0.000121 10.6210 10
57340 21284.762 0.001395 10.6263 10
57340 22308.765 -0.000356 10.6249 10
57340 23332.765 0.000342 10.6262 10
57340 25696.767 0.133433 10.6262 6
57340 25760.767 0.104016 16.9749 6
57340 25824.771 0.080556 16.9749 6
57340 25888.771 0.001784 17.0838 6
57340 25952.762 0.000949 17.1417 6
57340 26016.764 0.000401 17.1662 7

Odpovědi

[NN]

Resil jsi to nejak? Co se v tom okamziku delo? NTP troubleshooting mozna/pomuze.

[Jarda]

Ahoj. Zatim ne, ale vsem dekuji za reakce. Nemel jsem zatim cas to resit. Az neco budu vedet, hodim to sem.

[cronin]

Zaujímalo by ma, o aké aplikácie ide, že im časový rozdiel desatiny sekundy spôsobuje problémy. ale to len tak na okraj.

Raz sme robili pre klienta, ktorý bol presvedčený, že potrebuje tak presný čas, že jediná použiteľná možnosť pre neho je čas z GPS. Nakúpil na to príslušný HW - ktorý v tom čase bol príšerne drahý a ťažko zohnateľný -- a umiestnil ho dve poschodia pod zem. Nie je ťažké uhádnuť, že to dopadlo fiaskom. Navyše, pre jeho účely úplne postačoval nejaký náhodne dostupný stratum 4 server.

Nebolo by postačujúce mať v každej lokalite stratum 3 server synchronizovaný podľa niekoľkých, pokojne "cudzích" stratum 2 serverov? Z akého a koľkých zdrojov máte teraz synchronizovaný stratum 2 server? Podľa mojich skúseností je mať viacero redundatných NTP zdrojov s horším stratum levelom, ako mať jediný stratum 1 alebo 2 zdroj. Inak povedané, výpadky v dostupnosti jedného zdroja spôsobujú väčšie odchýlky ako odchýlky spôsobené samotnou horšou úrovňou stratum-u.

NTP server vedia robiť aj [polo-]inteligentné routre, v podnikovej infraštruktúre už dnes -- čítaj posledných aspoň 10 rokov -- nie je potrebné mať NTP na serveri.

[lertimir]

Přílohy:

• ntp_offset-week.png (49580 bytů)
• ntp_kernel_pll_freq-week.png (29034 bytů)

NTP je velmi dobrý protokol v tom, že výkyv je schopen efektivně dorovnat. V tom čase, který jsi vyznačil se něco významně v systému změnilo. Předposlední sloupeček je drift_compensation. které bylo 10 (ppm) a pak se něco změnilo, a čas začal ujíždět a proto se musela změnit tato kompenzace (z 10 na 17). A nějakou dobu mu trvalo než to zvládl. Co se v systému přesně stalo zjistíš z monitoringu.

Možné příčiny jsou: Významná změna zátěže systému (load z 0 na 5 a více), změna delay na externí lince (třeba při masívním downloadu nebo díky poskytovateli), velká zátěž na rozhraní (třeba masívní přenosy na lokálním NFS/cifs). Moje osobní zkušenost z NFS na dvou procesorovém serveru s XEONy (16 jader) byla taková, že když se nahodila zátež (load 20) server ujel 100 ms i více.

Prikládám snimky z muninu na mém domácím servříku z právě probíhajícího týdne. Na timingu byl problém s poskytovatelem, měl pár dní obrovský delay. Je vidět jak Offset skákal a přikládám k tomu i graf PPL frequency, jak to dorovnává NTP server. (grafy jsou synchronné a je možné je dát přes sebe). Když je klid tak se PPL drží v mezi 17 a 18 a mění se velmi pomalu. A offset je kolem 1ms. Nicméně stačí, když na serveru se rozběhne backuppc ze dvou strojů a výkyv kolem 10ms to dá také.

[j]

Zmen si systemovy hodiny ... (zdroj casu). Podle HW bys mel mit nekolik moznosti. Resil sem to ... peknych par tydnu nez sem to vykoumal a vygooglil.

cat /sys//devices/system/clocksource/clocksource0/current_clocksource

vrati atkualni

cat /sys/devices/system/clocksource/clocksource0/available_clocksource

vrati mozny

semhle to namastis: kernel /boot/k... root=/dev/ram0 ramdisk=8192 clocksource=acpi_pm

[j]

Jop, ve vychozim stavu sem tam mel tsc, a bylo to tak jebly, ze se z toho ntp dokonce pravidelne slozilo.

[lertimir]

To je ale situace typicky v notebooku, kde jsou velmi výrazné změny v napajení a frekvenci procesoru v závislosti na zátěži a uspoře. Pro servery je to v zásadě jedno. A jak již bylo napsáno Solaris je jiná hra.

[Ruda]

Fakt hodnotná rada pro Solaris.

[j]

A? Co maj nestabilni hodiny spolecnyho s arch?

[Ruda]

Á zase jeden pan chytrej. Tak znovu. Tvoje rada aby někam namastil clocksource=acpi_pm, je k prdu. Jinak architektura je SPARC, Solaris je operační systém.