Dotaz: NTP synchronizace

[ZdenekPetron]

Zdravím, mám problém s NTP server, respektive s jeho stabilitou. Distribuce je stable Debian lenny. server stratum 3 je napojen na 8 serveru, 7 z nich je blizko (pod 2 ms). Přesto není schopen dosáhnout stability a kmitá s amlitutou cca 150 ms kolem přesného času. Tady posílám výpis z příkazu ntpq/rl 4393 na nejbližší stratum 2. V posledních 3 řádcích je vidět jak se můj server vzdaluje od přesného času řádově o 5 ms za jeden dotaz, což v této chvili je dotazováno s intervalem 64 sec, i když je už poměrně daleko (120 ms).

assID=4393 status=91d4 reach, conf, sel_falsetick, 13 events, event_reach,
srcadr=abcdef.cz, srcport=123, dstadr=x.x.x.x,
dstport=123, leap=00, stratum=2, precision=-18, rootdelay=1.816,
rootdispersion=2.991, refid=a.b.c.d, reach=377, unreach=0,
hmode=3, pmode=4, hpoll=6, ppoll=6, flash=00 ok, keyid=0, ttl=0,
offset=-133.181, delay=0.595, dispersion=0.946, jitter=20.812,
reftime=ceaa7e98.6990e1df  Sun, Nov 15 2009 14:20:24.412,
org=ceaa7eb2.f2a78439  Sun, Nov 15 2009 14:20:50.947,
rec=ceaa7eb3.14d326a7  Sun, Nov 15 2009 14:20:51.081,
xmt=ceaa7eb3.14ab1a5e  Sun, Nov 15 2009 14:20:51.080,
filtdelay=     0.60    6.40    8.28    0.61    0.63    0.49    0.69    0.58,
filtoffset= -133.18 -127.19 -123.28 -121.58 -116.15 -110.49 -104.86  -99.17,
filtdisp=      0.00    0.99    1.95    2.91    3.86    4.85    5.82    6.81

Celkově mi jeho chování připadá jako netlumený harmonický oscilátor nebo možná ještě hůře se záporným tlumením, protože se s časem rozkmitává sále více. Včera měly kmity amplitudu cca 80-90 ms proti přesnému času. Perioda u těch kmitu je přibližně hodina. Nevíte někdo jak to doladit?

Odpovědi

[Petr Šobáň]

Proč tolik serverů ? Nestačily by třeba pouze 3 nejbližší ?

A je dostatečná propustnost sítě nestrácí se pakety, proměnlivé spoždění paketů a pod co to může ovlivňovat.

[a7dfa]

To vypada na nejaky bug v kernelu. Zkusil bych "disable kernel" v ntp.conf, jestli se to nezlepsi.

Urcite by se hodil loopstats log.

[ZdenekPetron]

Tak nevím. Předtím jsem to zkoušel asi 5x a nechal běžet několik dní a pořád hodiny kmitaly. Teď jsem udělal ještě jeden pokus. Snizil minpoll na 4 a zapnul všechny logování a hodiny jsou stabiní po 2 hodinách běhu.

org=ceaac3a5.e6887ab7  Sun, Nov 15 2009 19:15:01.900,
rec=ceaac3a5.e6d96680  Sun, Nov 15 2009 19:15:01.901,
xmt=ceaac3a5.e6b3b3fd  Sun, Nov 15 2009 19:15:01.901,
filtdelay=     0.55    0.58    1.36    0.59    0.60    0.57    0.53    0.57,
filtoffset=   -0.96   -1.11   -0.84   -1.38   -1.50   -1.64   -1.77   -1.93,
filtdisp=      0.00    0.96    1.91    2.85    3.83    4.80    5.75    6.69

Tak pozdeji zanalyzuji logy.

[ZdenekPetron]

Tak jsem byl přehnaně optimistický. NTP server se rozkmitává pořád. Chci se zeptat jak vám drží ntp u lennyho. Jádro u mne je 2.6.26-2-xen-amd64 a kus výpisu ze začátku loopstats.log tady:

55151 145.900 0.008428000 19.747 0.002846460 2.027542 6
55151 337.900 0.011902000 21.926 0.002932280 2.047130 6
55151 812.906 0.014909000 28.680 0.002941677 3.060796 6
55151 1072.906 0.017950000 33.131 0.002954337 3.267051 6
55151 1110.899 0.017933000 33.781 0.002763536 3.064671 6
55151 1305.901 0.017718000 37.076 0.002586168 3.094396 6
55151 1673.900 0.016638000 42.915 0.002449074 3.555323 6
55151 2012.902 0.012448000 46.939 0.002728174 3.617283 6
55151 2343.901 0.006291000 48.925 0.003354284 3.455734 6
55151 2515.903 0.003635000 49.521 0.003275146 3.239410 6
55151 2765.899 0.001887000 49.971 0.003125330 3.034362 6
55151 2915.902 -0.004441000 49.336 0.003681355 2.847259 6
55151 3337.899 -0.006363000 46.775 0.003509993 2.813046 6
55151 3533.900 -0.014744000 44.019 0.004422656 2.805973 6
55151 3661.901 -0.016347000 42.024 0.004175672 2.717911 6
55151 4081.899 -0.022812000 32.887 0.004525560 4.110924 6
55151 4427.899 -0.023630000 25.089 0.004243137 4.731472 6
55151 4534.901 -0.023710000 22.670 0.003969191 4.507792 6
55151 4833.901 -0.021872000 16.433 0.003769270 4.758396 6
55151 4980.902 -0.020210000 13.600 0.003574464 4.562394 6
55151 5107.900 -0.020325000 11.138 0.003343853 4.355572 6
55151 5594.901 -0.016403000 3.520 0.003421424 4.884081 6
55151 5624.901 -0.010403000 3.222 0.003839778 4.569851 6
55151 5660.901 -0.007829000 2.954 0.003705258 4.275760 6
55151 5725.901 -0.006099000 2.576 0.003519508 4.001840 6
55151 6075.898 -0.002322000 1.800 0.003552699 3.753395 6
55151 6143.898 0.004031000 2.062 0.004011122 3.512196 6
55151 6208.902 0.007320000 2.516 0.003928153 3.289273 6
55151 6336.899 0.009347000 3.657 0.003743697 3.103165 6
55151 6399.899 0.009847000 4.248 0.003506367 2.910272 6
55151 6911.901 0.021650000 14.820 0.005307538 4.623850 6
55151 7136.957 0.024135000 19.998 0.005041903 4.696807 6
55151 7432.899 0.031896000 29.002 0.005456386 5.425509 6
55151 7592.903 0.034363000 34.246 0.005177958 5.403078 6
55151 8007.902 0.033619000 47.551 0.004850678 6.904624 6
55151 8375.899 0.029735000 57.987 0.004740612 7.438227 6
55151 8657.900 0.026207000 65.035 0.004606470 7.390578 6
55151 8761.903 0.016759000 66.697 0.005452263 6.938185 6
55151 8941.945 0.011792000 68.721 0.005393958 6.529418 6
55151 9156.915 0.009330000 70.634 0.005120108 6.145047 6
55151 9427.900 0.000281000 70.707 0.005759757 5.748222 6
55151 9691.899 -0.010729000 68.006 0.006646790 5.461125 6
55151 9886.900 -0.025835000 63.201 0.008196360 5.383422 6
55151 10363.921 -0.038254000 45.799 0.008835244 7.950571 6
55151 10530.902 -0.044299000 38.744 0.008536529 7.844243 6
55151 10661.899 -0.046864000 32.889 0.008036520 7.624005 6
55151 11089.901 -0.048186000 13.221 0.007531983 9.960652 6
55151 11346.900 -0.047873000 1.488 0.007046394 10.199110 6
55151 11440.900 -0.045132000 -2.558 0.006662139 9.647032 6

Jako signifikantní mi připadá hlavně 4 sloupec (diference, nebo kompenzace driftu) ta by měla se ustalovat ale rozkmitává se a je vidět, že třeba při pruchodu hodnoty v třetím sloupci nulou (což je přesný čas) je 4 pořád dále od rovnováhy (nekde kolem cca 2)a hodiny proběhnou nulou čím dále rychleji. Něco je špatně v tom nastavení pro slewing, kmit se netlumí a zvětšuje. Nakonec se kmit dostane tak daleko, že zabere ten druhý mechanismus NTP - steeping, hodiny skočí jednorázově na přesný čas, a rozmitávání pokračuje znovu od začátku. Tady je pozdější část výpisu z dnešního večera

55151 49817.201 -0.041739000 -66.877 0.012851299 17.168982 6
55151 49882.200 -0.040563000 -69.391 0.012028477 16.084698 6
55151 50393.201 -0.001224000 -69.988 0.017889633 15.047335 6
55151 50586.201 0.000433000 -69.908 0.016744475 14.075521 6
55151 50723.204 0.036020000 -65.202 0.020090550 13.271161 6
55151 50910.202 0.045106000 -57.158 0.019065581 12.735644 6
55151 51172.203 0.063584000 -41.270 0.018993159 13.170904 6
55151 51518.215 0.110223000 -4.900 0.024239358 17.808417 6
55151 51566.200 0.112391000 0.245 0.022686796 16.757265 6
55151 52006.200 0.121623000 51.280 0.021471101 23.901402 6
55151 52135.201 0.126260000 66.813 0.020151170 23.022308 6
55151 52329.200 0.126122000 90.147 0.018849756 23.061525 6
55151 52461.200 0.118782000 105.100 0.017822321 22.210430 6
55151 52465.200 0.116523000 105.544 0.016690363 20.776550 6
55151 52706.220 0.101738000 128.927 0.016464330 21.119954 6
55151 52919.201 0.086932000 146.586 0.016266241 20.718947 6
55151 53249.202 0.060677000 165.682 0.017823732 20.523076 6
55151 53437.201 0.034551000 171.877 0.019060243 19.322107 6
55151 53438.201 0.028855000 171.904 0.017942588 18.074179 6
55151 53959.203 -0.017007000 163.454 0.023336852 17.168784 6
55151 54094.201 -0.050798000 156.914 0.024884978 16.225528 6
55151 54217.200 -0.067402000 149.008 0.024006625 15.432860 6
55151 54605.201 -0.119836000 104.665 0.029119488 21.311558 6
55151 55551.991 0.000000000 104.665 0.000000954 19.935137 4
55151 55594.006 -0.005050000 104.458 0.001785509 18.647757 6
55151 55649.994 -0.005748000 104.157 0.001688293 17.443705 6
55151 55714.993 -0.005664000 103.805 0.001579532 16.317564 6
55151 55777.991 -0.005926000 103.449 0.001480432 15.264202 6
55151 55973.992 -0.022412000 99.260 0.005990656 14.354969 6
55151 56187.992 -0.035184000 92.080 0.007196769 13.665726 6
55151 56293.991 -0.044389000 87.592 0.007477389 12.881187 6
55151 56673.991 -0.056754000 67.025 0.008248247 14.073444 6
55151 56800.991 -0.079227000 57.429 0.011075107 13.594624 6
55151 57312.993 -0.086009000 15.433 0.010633660 19.549327 6
55151 57537.992 -0.092855000 -4.492 0.010237136 19.596618 6
55151 57652.992 -0.089585000 -14.317 0.009645466 18.657180 6
55151 58032.995 -0.084727000 -45.022 0.009184542 20.553022 6
55151 58272.018 -0.071303000 -61.342 0.009815229 20.072768 6
55151 58369.993 -0.043494000 -65.365 0.013452309 18.830164 6
55151 58504.992 -0.046128000 -71.304 0.012617900 17.738710 6
55151 58569.991 -0.036508000 -73.567 0.012283211 16.612324 6
55151 58676.992 -0.023656000 -75.981 0.012355787 15.562825 6
55151 58792.990 -0.017786000 -77.949 0.011742627 14.574302 6
55151 59211.989 0.027119000 -67.112 0.019305709 14.161131 6
55151 59558.005 0.050079000 -50.540 0.019799342 14.484506 6
55151 59738.993 0.077672000 -37.206 0.020932821 14.345657 6
55151 60131.992 0.093442000 -2.185 0.020359212 18.258869 6
55151 60255.991 0.109841000 10.804 0.019907345 17.686245 6
55151 60447.993 0.125617000 33.806 0.019438974 18.434601 6
55151 60638.991 0.126238000 56.800 0.018184822 19.064324 6
55151 60701.991 0.125936000 64.367 0.017010678 18.032574 6
55151 61087.993 0.112823000 105.899 0.016573676 22.363868 6
55151 61307.992 0.110297000 129.040 0.015528962 22.462510 6
55151 61340.992 0.094752000 132.022 0.015530994 21.038188 6
55151 61403.993 0.095950000 137.787 0.014534094 19.784686 6
55151 61917.992 0.064821000 169.561 0.017491931 21.649642 6
55151 62210.990 0.032193000 178.557 0.020019854 20.499602 6
55151 62434.994 -0.008908000 176.654 0.023703478 19.187421 6
55151 62858.993 -0.063620000 150.929 0.029424503 20.121159 6
55151 62922.990 -0.098261000 144.931 0.030125906 18.940683 6
55151 62988.992 -0.100641000 138.597 0.028192771 17.858379 6
55151 63921.772 0.000000000 138.597 0.000000954 16.704984 4
55151 63948.776 -0.005915000 138.444 0.002091407 15.626174 6
55151 63953.774 -0.006356000 138.414 0.001962526 14.616951 6
55151 63964.794 -0.008058000 138.329 0.001931893 13.672939 6
55151 63999.771 -0.010674000 137.973 0.002029977 12.790483 6
55151 64459.770 -0.042556000 119.304 0.011430933 13.664292 6
55151 64589.770 -0.044815000 113.748 0.010722439 12.931840 6
55151 64941.774 -0.074640000 88.692 0.014552990 14.993491 6
55151 65099.772 -0.102885000 73.189 0.016883248 15.058094 6
55151 65221.772 -0.114440000 59.874 0.016312668 14.851388 6
55151 65551.772 -0.119799000 22.172 0.015376287 19.252938 6
55151 65883.785 -0.122427000 -16.591 0.014413162 22.630964 6
55151 66063.772 -0.122426000 -37.606 0.013482279 22.435431 6
55151 66305.770 -0.102919000 -61.359 0.014374084 22.604274 6
55151 66822.770 -0.073087000 -97.395 0.017088933 24.686105 6
55151 67099.771 -0.058722000 -112.907 0.016772579 23.734108 6
55151 67148.770 -0.023018000 -113.983 0.020137168 22.204482 6
55151 67660.772 0.014313000 -106.994 0.023000340 20.916847 6
55151 67749.785 0.054777000 -102.345 0.025837173 19.634847 6
55151 67999.772 0.084954000 -82.090 0.026418695 19.713384 6
55151 68056.772 0.105098000 -76.377 0.025718197 18.550477 6
55151 68120.771 0.103884000 -70.036 0.024061000 17.496587 6
55151 68186.771 0.113981000 -62.862 0.022788376 16.561943 6
55151 69149.990 0.000000000 -62.862 0.000000954 15.492280 4
55151 69173.993 0.002452000 -62.806 0.000867090 14.491714 6
55151 69176.994 0.002586000 -62.799 0.000812460 13.555758 6
55151 69485.997 0.019067000 -57.180 0.005876319 12.834915 6
55151 69719.993 0.040129000 -48.225 0.009255636 12.416424 6

Skoková synchronizace nastáva v časech 55551.991, 63921.772 a 69149.990. Pomohlo by mi když byste se ozvali uživatelé s lennym, jak stabilní hodiny mají oni? Možná jich je má nestabilní více jen si nevšimli. Je jasné, že s chybou 100ms se dá žít, ten steeping to dále nepustí, ale proč to nedoladit na přesno. Ještě někdo se ptal na rychlost připojení, mašina je 2x4jádrový xeon 5000 s 72GB paměti a 1GB připojením a plnou 1GB propustností na většinu NTP serverů. Je v reku v klimatizované servrovně takže ani teplotní fluktuace nejsou významné. A jen poznámka, na domácím desktopu mám opensuse a to je přesné, v rámci tedy toho, co mnohem horší ADSL linka dává. Může to být chyba v distribuci, proto se ptám lidí s běžícím lennym, kdy někdo mohl posunout konstanty s ideou "zrychlí se tím konvengence", ale nedošlo mu, že když to přežene, systém se rozkmitá.

[a7dfa]

Jo, tohle rozhodne vypada na rozhaseny PLL v kernelu, mozna prilis kratka casova konstanta, co pise ntptime?

Zkuste to "disable kernel" do ntp.conf nebo -x parametr, tim se vyradi PLL v kernelu a ntpd bude pouzivat vlastni.

[ZdenekPetron]

Díky, klausule "disable kernel" pomohla. Server provedl 1 výkmit asi na odchylku 50ms a teď se velmi pomalu blíží k 0. Je na odchylce 20ms a za cyklus dotazu 64 sekund se přiblíží o cca 0.1ms. Teď ještě je otázka, co s tím dále. Je to podle Vás chyba jádra? A měla by se pak reportovat do bugzilly Debianu? V hardware to asi není, když samotné ntpd vypadá dobře. Pokud by tuhle chybu někdo potvrdil, tak ji do bugzilly napíšu. Může to být i rozšířená chyba, které si lidi nevšimli, protože do 100ms se ta synchronizace udrží, takže bez koukání na ntpq nebo do logu to vidět není. Moje jádro je 2.6.26-2-xen-amd64, hodiny jsou na dom0 a distro Debian.

[a7dfa]

Nareportovanim bugu se nic nezkazi :).

Predpokladam, ze v syslogu se objevovaly hlasky o time reset, tak by si toho snad vsimlo vic lidi, kdyby se to delo vsude.

[ZdenekPetron]

Jo v syslogu jsou hlášky time reset, ale také jsou tam i hlášky synchronized to pokaždé když ntpd přehodí na která server se primárně navěšuje. Nemuseli si toho lidi všímat. Zkusím mu to zarazit at tam tolik nepíše.

[ZdenekPetron]

Řešení s disable kernel bohužel není funkční. Sice se mi hodiny na dom0 pěkně zasynchronizovaly a jsou opravu přesné, ale disable kernel také způsobil, že se odpojily od hodin na dom0 hodiny na virtuálech domU a nemají žádnou synchronizaci.

[a7dfa]

Tak potom jeste muzete vyzkouset chrony misto ntpd, ten nepouziva PLL vubec.

[ZdenekPetron]

No vzhledem k tomu, že je to server s asi 10 virtuály tak prostor na experimenty není. Rebootovat dom0 asi nemohu dříve než na vánoce. Teď je pro mne podstatné je, jak přebírají domU čas z dom0. Měl jsem takovou představu, že když jsem vyřadil "disable kernel", tak vlastně v ntpd vytvořilo vrstvu s níž pracovaly programy v dom0, ale jádro mělo svůj čas a ten předávalo do dom0. Z dokumentace chrony mi připadá, že to bude také jen vrstva, do jádra se ten čas nedostane a tím pádem se stejně nepřenese do domU. A jen na okraj, s kamarádem jsme se podívali na další 4 servery jedoucí pod debianem. U dvou z nich je stejný problém, čas je dorovnáván steepingem, pomalé přibližování nefunguje.

[kyytaM]

No pozriem zajtra na svoj Lenny based Dom0, ci ma tiez ten isty problem. Co som sa stretol na diskusiach, tak bol aj problem s tym, ze DomU hodiny sa rozchadzali s Dom0, vtedy sa ako riesenie ponukalo ntp do kazdej DomU...

Otazka troska bokom - co som chvilu patral a zistoval, tak Debian Lenny so svojou standardnou Xen suitou PCI pass-thru na PV DomU nepodoruje. Neexperimentoval si s tym nahodou niekedy? :)

[ZdenekPetron]

Samostatné ntp v různých domU mě připadá úplně na hlavu. Pokud mám přesné hodiny na dom0, tak je jen otázka na to, jak je přenést hardwarově do domU. Teď jsou hodiny ve všech dom stejné. Steeping na dom0 také funguje, hodiny se skokem pomocí ntp dorovnáváji. To co nefunguje je ten skeewing tedy jemné dorovnávání konstant při běhu. Ale také podle toho výpisu logu, který jsem sem již hodil tak je to zvláštní. Není to že by skeewing nefungoval, ntpd mění konstanty běhu času v jádře, ale spíše jako by tam chyběla zpětná vazba, diference, která je v následujícím sloupci za odchylkou nabývá obrovských hodnot a hlavně strašně rychle se mění. Z teorie regulace plane, že takto systém dopadne, když je takzvaně přeregulovaný, tedy když regulační člen odpovídá na odchylku rychleji a silnějším stimulem, než je systém přijmout. Z toho mí spíše plyne, že ntpd neví, co se ve skutečnosti v jádře děje a při odchylce tlačí více na pilu než by měl. Když se vyřadila komunikace s jádrem, tak diference velmi velmi pomalu klesala a ntpd doregulovával hodiny z odchylky 30ms na 0.1ms celé 4 dny, změny v položce diference mezi jednotlivými zápisy v logu byly jen na 3 nebo 4 platné cifře, a na polovinu se změnila tak za 20 hodin. Tady je na polovině za 100 vteřin. Pro mne je teď v tomhle hlavní otázka, jak takovou regulaci udělat v jádře nebo spíše co komunikaci blokuje a zřejmě to bude muset být nové jádro trochu jinak sestavené. Zatím jsem našel tohle Known Operating System Issues. Mimo jiné první věta v sekci o Xenu a virtualizaci je, že ntp není určeno na provoz ve virtuální mašině. Ale v článku jsou parametry jádra, které stojí za zvážení. Ale než budu dost přesně vědět, co se děje a co mám ovlivnovat tak s kmitáním kolem 150ms budou muset ty virtuály žít.

[a7dfa]

Jeste by mozna stalo za to zkusit pridat klicove slovo burst do ntp.conf jak je uvedeny NTP server.

By se tim teoreticky mohl zvysit pocet uprav PLL a dostat to do stabilniho stavu.

[ZdenekPetron]

Zkusím, ale pochybuji. To není o počtu úprav, ale v tom že ntpd o PLL v kernelu nic neví. Příkaz ntpdc -c ker hlásí hodnotu pll 0 a status 0040 unsync. Takže si myslím že ntpd se snaží, posílá změny hodin, to se mu daří, hodiny se posunují, ale nemá žádnou zpětnou vazbu, neví o PLL v jádře, tak přitlačí na pilu začne měnit více a tím to rozkmitá. Fakticky má asi jen informace o stavu (odchylce) hodin a to mu nestačí.

[kyytaM]

Predpokladam, ze ide o paravirtualizovany DomU?

[ZdenekPetron]

jde o dom0. paravirtualizované domU nemají vlastní čas a berou čas z dom0.