reklama

Loadbalancing NTP serveru

jouda

Re:Loadbalancing NTP serveru
« Odpověď #15 kdy: 10. 01. 2019, 00:03:58 »
Nebo se pletu?
Hele já ti nevím, o kus výš jsou dal dva linky na dokumentaci (ntpd + RedHat), která ti jasně sděluje, že to nebude správně fungovat.
Moment - já tvrdil že když mám v síti dva NTP servery které tvrdí že je stratum < 16 a ukazují rozdílný čas, tak je něco hodně špatně, což by za normálního provozu nemělo nastat (a implicitně předpokládal, že to odchytí monitoring a někdo to bude řešit).
O tom, že když jsou dva stratum2 servery a jeden z nich kecá, tak s tím klient nic moc nenadělá se nehádám, to je jasné i bez odkazů.

Napadá mě v případě, že jsou klienti citliví na nedostupnost ntp
https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/maximum-tolerance-for-computer-clock-synchronization

Při rozdílu pět minut mezi klientem a serverem jseš v péérdeli. Jako fakt nevím, jestli to má smysl dál rozebírat.
[/quote]
To je zase o něčem jiném, to že 5 minut je průser netřeba rozepisovat, to ví každej. ;-)
Co jsem psal je, že když někdo restartuje (třeba kváli patchování, to je fuk) ntp takže to dejme tomu 5 minut neběží vůbec, a pak dalších 20 minut to vrací stratum16 než se sesynce, tak by to správně moc vadit nemělo, klientovi běží vlastní hodiny +- normálně, s driftem to počítá a do hodiny se to zase srovná podle ntp, pro běžné protokoly a situace je to dostatečné (i ty logy by na běžném serveru neměly ujet o víc než sekundu).

Já psal o tom, že občas se vyskytne vysoce specializovaná krabička, které když se tohle stane, tak dělá totální kraviny a tam dává smysl tam předhodit LB čistě kvůli HA. O běžných linux nebo windows stanicích řeč není.

No, správnou implementací NTP klienta hlavně není "hoď si mincí", takže to - hrozně překvapivě - ani nedělá.
No když hračka v šestimístné ceně v eurech po ztrátě spojení s NTP (kterej navíc jde nadefinovat jen jeden), aniž by se tomu čas reálně rozjel,  začne posílat alarmy že je rozpadlé spojení s dejme tomu backendem (sorry NDA, o co konkrétně šlo nenapíšu), tak je tam špatně víc než jen házení mincí.
Nebo mnohem levnější hračka co má něco naměřit a odeslat, když jí neodpoví ntp tak jak očekává, tak ani nic neodečte.

Citace: j
Treba nechce do internetu posilat seznam vseho co ma v siti, ze ... to je takovej zcela neobvyklej pozadavek v naprosto drtivy vetsine siti.
Tak pustit klienta přímo na pool.ntp.org? To je vtipné zvlášť když se ten klient když je vypnutej časově rozjede a současně má zapnutou validaci dnssec. ;-)

reklama


Re:Loadbalancing NTP serveru
« Odpověď #16 kdy: 10. 01. 2019, 00:53:12 »
(Jsem ve střetu zájmů: tento obor mě živí.)

Děkuji M. za zmínku o značce Meinberg :-) Mimochodem ten Geode na 500 MHz zvládne bez autentikace zodpovědět 10k NTP transakcí za sekundu. Slušně vychovaný NTP klient se ptá jednou za desítky sekund až jednotky minut (pseudonáhodný interval). Takže spíš stovky tisíc slušně vychovaných klientů. Ale jak M. a další správně píšou, zdaleka ne všichni NTP klienti jsou zdvořilí a inteligentní.

Geode má tu výhodu, že jak CPU tak zbytek čipsetu (sběrnice) jsou jednoduché jako koloběžka = má to krátké a deterministické latence, což je optimální podvozek, pokud Vám jde o přesnost, minimální jitter. Ntpd běžící na Geodovi s kvalitní GPSkou vidí jitter PPS vstupu běžně do 1 mikrosekundy = na hranici toho, co dokáže ntpq vůbec nahlásit. Dnešní výkonnější procesory s košatým stromem PCI-e sběrnic, message-signaled interrupty apod. může mít determinismus latence obsluhy IRQ citelně horší. Jinak se říká, že NTP dokáže za ideálních podmínek (nezatížený Ethernet, Linux a v něm plnohodnotný ntpd na klientu i serveru) dosáhnout přesnost cca 20-50 us.

Popravdě zmínku, že někdo zkouší load-balancovat NTP nějakým generickým "content switchem", to slyším prvně :-) U NTP jde o časování (minimální jitter, minimální rozptyl round-trip zpoždění) a u jednotlivé NTP asociace může mít smysl, aby transakce po sobě jdoucí se ptaly vždycky téhož upstream serveru. Pokud se totiž servery v clusteru trochu rozejdou, a ten balancing je per transaction (nikoli per NTP "session") tak to bude z klienta vypadat, jako že syntetický balancovaný server má hrozný jitter. Pravda je, že u load-balanced clusteru bych předpokládal, že servery budou mít mizivý vzájemný offset, protože budou někde pohromadě a budou mít optimálně shodný upstream zdroj...

Máte-li v síti nějaké NTP klienty, kteří jsou tupí a nevychovaní, a máte důvodné obavy, že by mohli vymazlené rádiem řízené servery na stratu 1 poslat za určitých okolností do kolen, není nic jednoduššího, než vyrobit pro ně 1-2 nebo více serverů na stratu 2. Linux, ntpd nebo Chrony (podle osobní libosti), pár řádek v konfiguraci, hotovo. Pokud pro stratum 2 použijete nějaké trochu výkonnější železo než je Geode, tak tyhle servery budou mít i lepší šanci ustát "DoS příval" než Geode nebo ARM apod. v rádiem-řízeném serveru. Kromě toho na "Meinberga" už případný "zombie útok zvlčilých SNTP klientů" především vůbec nedoputuje, což je hlavní cíl. Vanilkový ntpd tuším dodnes jede v jediném vlákně (a není úplně trivka to rozložit na víc jader) takže nemá smysl postavit na tuhle pozici 12jádrový Xeon. Ale ono i Core2Duo nebo nějaký moderní BayTrail ATOM tomu Geode natrhnou tričko (za cenu vyššího topného výkonu, pochopitelně).

Mimochodem Meinbergové dokázali to rozvláknění nějak pořešit po svém - prodávají nějaký vcelku béžový 1U server se svým vlastním Linuxem, který zvládne snad 320k Tps (80k jedním vláknem) a servíruje to softwarově. Kromě toho mají Meinbergové modul PTP grandmasteru s FPGA implementací PTPv2 nebo NTP - tenhle modul zvládne hardwarově odpovědět taky na cca 300k NTP Tps, při spotřebě asi 5W a při přesnosti časových značek někde v desítkách ns (dáno přesností GPS přijímače, který tomu dodává referenci = PPS a 10 MHz). Má to nějaké další technické nuance, každopádně cenovky jsou lehce astronomické.

Zpátky na zem. Tzn. nejlepší "NTP balancer" je IMO dedicated serveřík pro stratum 2 s Linuxem (nebo jestli má někdo radši BSD, vyjde to asi podobně). Nebo servery dva, aby se vzájemně zálohovaly. A nepotřebují mít mnoho jader.

Nabízí se nápad, vyrobit to stratum 2 ve virtuálu - tohle se už tuším tady probíralo, že tradičně NTP ve virtuálu je hřích, ale novější informace říkají, že už to v nových verzích hypervizorů není taková hrůza jako bývala. Osobně bych doporučil vyhradit "NTP virtuálu" celé CPU jádro, pokud už se tím chcete zabývat. A jako guest OS (nebo na holém železe) pro běh ntpd/Chronyho každopádně nějaký Linux. Jestli si pak ještě zkusíte hrát s podporou high-resolution timerů (nevím zda to pro ntpd má smysl) nebo zkusíte real-time kernel, to už je čistě na Vašem vkusu a zálibách. Ale i běžné distribuční jádro poskytne rozumnou službu.

Někdo taky provozuje stratum 2 na páteřních switchích LAN (větší Cisco apod.) - je asi věcí posouzení rizika, jestli to neohrozí management CPU přetížením.

Pokud nechcete dobročinně servírovat NTP do divokého internetu, tak v běžné firmě nebudete mít v síti pohromadě tolik klientů, aby položili třeba jenom toho Geode. Nějaké příhody z natáčení by se našly, když to výrobce SNTP klientů nevzal za správný konec... ale nemá cenu vláčet tyhle případy veřejně blátem. Tyhle historky slýchám i přímo od výrobců klientských krabiček a to v tom smyslu, že si z incidentu vzali správné ponaučení.

Meinbergovic proprietární NTP "cluster" (pro hloupé klienty, kteří umí v konfiguraci jenom 1 upstream NTP server) funguje do jisté míry analogicky jako HSRP/VRRP = servery si navzájem půjčují IP adresu (patrně nikoli MAC adresu). Ovšem aktivní je vždy pouze jeden Meinberg v clusteru. Tzn. pro rozkládání zátěže to použitelné není.

Tik a Tak u Cesnetu bývali tradičně hodně vytížení. Asi bych nedoporučoval, obracet se na ně přímo. Použijte třeba 5 aliasů z pool.ntp.org a on už si to Váš ntpd přebere.

V tom výpisu "ntpq -p" mě reach=377 nijak nešokuje, to vypadá dobře. Reach je octal bitmaska posledních pár pokusů (NTP transakcí) proti dotyčnému upstream serveru. Spíš mě tam šokuje jitter 140 ms. Z pool.ntp.org běžně dostanu některý server se stabilním jitterem a ofsetem v nízkých jednotkách ms.

Plnohodnotný ntpd (nebo Chrony) si skutečně vybírá server nebo malou skupinku serverů s navzájem blízkým ofsetem a co nejnižším rozptylem (jitterem). Takže pokud klientovi/klientům nebo "svému NTP serveru" nakonfigurujete větší počet upstream NTP serverů, dojde automaticky k rozložení zátěže mezi upstream servery i na té bázi, že přetížené servery mají horší jitter a z "volby" vypadnou jako první. Zátěž bude nakonec směřována přednostně na méně vytížené upstream stroje.

Druhou fajn vlastností plnohodnotné implementace NTP je, jak již zmíněno, detekce a odmítnutí lhářů (falsetickers) - viz obrázek s titulkem "intersection interval". Jde o svého druhu algoritmus pro shlukovou analýzu na bázi konsezu kvóra a "outlier rejection". Věc jde dokonce tak daleko, že pokud přímo na serveru s GPS přijímačem dáte "refclock driveru" direktivu "prefer", aby "vžycky zvítězil", tak pokud vedle refclock driveru uvedete v konfiguraci také pár upstream NTP serverů z divokého internetu, mohou ve "volbě" vytěsnit refclock driver včetně jeho "prefer" přídomku jakožto falsetickera, pokud se svým názorem na přesný čas zůstane osamocen (viz poslední odstavec v kapitole 5 na uvedeném odkazu).

Pokud budete někdy řešit nějakou redundantní NTP topologii uvnitř rozsáhlejší sítě, doporučuji držet se striktní hierarchie klient/server (master/slave). On ntpd umí nakonfigurovat i "peer to peer" asociaci, ale některé praktické zkušenosti říkají, že není radno konfigurovat to "do kruhu", kromě toho se pak taková konfigurace chová dost "automagicky" i na poměry ntp algoritmů. Striktní hierarchie je jistota.

Naopak pokud budete mít v lokální síti několik kvalitních rádiem řízených zdrojů, a budete o stratum níž pozorovat "clock hopping", tak vězte, že to ničemu nevadí.

Holé minimum (počet upstream serverů) pro outlier rejection (detekci manipulace) je patrně 3. Pokud máte v lokální síti 3 rádiem řízené NTP servery, mělo by to stačit. Podotýkám, že samotný GPS přijímač dokáže samozřejmě detekovat a přes NTP dál předávat chybové stavy, jako je ztráta příjmu z družic nebo hrubý pokus o manipulaci. A pokud by se nakonec někomu povedlo, přijímač GPS zmanipulovat ke skokové změně hlášeného času, tak se vzápětí sám vypne ntpd (nebo se vykašle na dotyčný refclock driver, pokud má nakonfigurované další upstream zdroje), protože ntpd si toho skoku taky všimne a považuje ho za vážnou chybu.
Zpět k tématu: pokud jde o "minimální počet pro outlier rejection"... servery z divokého internetu bývají na štíru s dostupností, takže má smysl požadovat 4 nebo víc upstream serverů. Lichý počet je možná teoreticky lepší, aby nemohlo dojít k "patu" - ale on skutečný počet upstream NTP asociací bude beztak po svém vandrovat mezi sudými a lichými čísly podle reálné dostupnosti nakonfigurovaných serverů, a v NTP poolu je zřejmě dost serverů s poměrně mizerným round-tripem a jitterem. Výpis ntpq na stroji, který bere čas z divokého internetu, je obvykle mnohem barvitější a zajímavější, než výpis ntpq v síti s několika lokálními rádiovými zdroji (v ntpq skoro samé nuly).

Ohledně PTPv2... ano připomíná to legendu o babylonské věži. Jednomu vendorovi PTP klientů (a třeba switchů) se konfigurací grandmastera ještě přizpůsobíte, ale v multi-vendor heterogenních sítích může být těžké najít společného jmenovatele.
Mimochodem na takové to domácí žvýkání PTPv2 doporučuji linuxptp a hardware i210 ev. i350 - případně může být zajímavé pohrát si s PPS vstupem nebo výstupem na GPIO pinech i210. Případně zavěsit jeho 25MHz krystal na vnější kvalitní referenci (GPS, Rubidium apod). Pokud pro to máte využití (vedle PTP třeba capturing provozu s přesnými časovými značkami - rozlišení v ns) tak si užijete třeba i dost zábavy.

daemon

Re:Loadbalancing NTP serveru
« Odpověď #17 kdy: 10. 01. 2019, 08:21:07 »
Má smysl provozovat NTP servery ve virtualizaci? Dejme tomu ve vmware. Nějak podvědomě mám pocit, že by to nemusel být úplně dobrý nápad ve smyslu dopadu na přesnost. Nijak systematicky jsem se ale tou problematikou nezabýval, takže se možná pletu.
Používám veřejné stratum 1 servery od CESNETu, CZ.NIC a UFE AVČR - Národní časové laboratoře a uvnitř LAN mám pár NTP serverů, které jsou na bare metal strojích.

Re:Loadbalancing NTP serveru
« Odpověď #18 kdy: 10. 01. 2019, 08:52:52 »
Má smysl provozovat NTP servery ve virtualizaci? Dejme tomu ve vmware. Nějak podvědomě mám pocit, že by to nemusel být úplně dobrý nápad ve smyslu dopadu na přesnost. Nijak systematicky jsem se ale tou problematikou nezabýval, takže se možná pletu.
NTP ve virtuálu: jasně že to není správně, ale pro někoho má virtuálka zřejmě praktické výhody, takže se výrobci hypervizorů zřejmě dost snaží, aby to až tolik nebolelo. Ono se to tady už probíralo :-) a možná ne jednou.

Používám veřejné stratum 1 servery od CESNETu, CZ.NIC a UFE AVČR - Národní časové laboratoře a uvnitř LAN mám pár NTP serverů, které jsou na bare metal strojích.

To mi přijde jako rozumná kombinace. Nezkoumal jsem, ale v téhle množině by měl být k nalezení alespoň jeden server, který nekolabuje přetížením. Konkrétně CZ.NIC si dává dost záležet na průchodnosti poskytované infrastruktury.

V rovině "zážitků z natáčení" (jedna paní povídala) jsem zaslechl o národním etalonu času v jedné východoevropské zemi, kde si postavili veřejný NTP server, a po zveřejnění IP adresy jim za nějakou dobu začla "záhadně" kolabovat IP konektivita do sídla dotyčného úřadu - příčinou byl právě nápor NTP dotazů zvenčí.

j

Re:Loadbalancing NTP serveru
« Odpověď #19 kdy: 10. 01. 2019, 09:05:12 »
Má smysl provozovat NTP servery ve virtualizaci? Dejme tomu ve vmware. ...
Vmware host ma vlastni ntp a je doporuceny ho mit zaply. Klienstky hodiny se bydefault ridi hostem. Tudiz je to mozny, ale zbytecny, pokud to teda nechces provozovat jako ntp server.


daemon

Re:Loadbalancing NTP serveru
« Odpověď #20 kdy: 10. 01. 2019, 09:56:52 »
O to mi právě jde - provozovat NTP server v dané lokalitě jako virtuál. Jde totiž o to, že z toho páru, který jsem zmínil výše, v tuto chvíli jeden je mimo provoz, protože není k dospozici vhodný hardware. Měl jsem to na Sun Fire V120, ale nějak začal kriplovat. Mimo to jsem ten stroj chtěl šetřit pro muzeální účely a nechtěl jsem, aby byl trvale v provozu. Mám tam ale dostatek kapacity ve virtualizaci.
Protože to je převážně hobby projekt, nový hradware na NTP server pořídím, až se naskytne vhodná příležitost - ve správné popelnici bude vyhozený vhodný hardware, který já ještě upotřebím.
A mám tam ještě NTP server na Mikrotiku, ale to se mi nelíbí. Router má routovat, ne dělat NTP server.

Vilith

  • ****
  • 375
    • Zobrazit profil
Re:Loadbalancing NTP serveru
« Odpověď #21 kdy: 10. 01. 2019, 10:02:35 »
Pokud neni provoz (presnost) ntp serveru bussiness critical, tak provozu ve virtualu nic nebrani.

V tom pripade trochu nechapu proc porizujete vlastni specialni HW na NTP sluzbu, kdyz muzete pouzit NTP z hranicniho routeru site LAN (nebo z internetu) nebo z libovolneho fyzickeho stroje (stroju) synchronizovaneho proti internetu

David1234

Re:Loadbalancing NTP serveru
« Odpověď #22 kdy: 10. 01. 2019, 10:27:12 »
K těm dvěma ntp serverům - Zkusil sesynchronizovat na testovacím serveru čas a zapnout ntpd s dvěma HW ntp servery (mají GPS anténu). Jak je možné že jsou plně synchronizované 377 ale ntpd je oba označil jako lháře? Zkoušel jsem porovnat časy které vrací skriptem (https://gist.githubusercontent.com/crashdump/5704286/raw/351511e82d427f7cae68bbba5bdb1323fb36ba01/compare-ntp-time.py) a časy vrací stejné. Kde je problém? Tušíte někdo kde může být zrada?

Kód: [Vybrat]
[root@server ~]#service ntpd stop
[root@server ~]#ntpdate -s clock-02.domain.tld
[root@server ~]#service ntpd start

[root@server ~]# ntpq -p 127.0.0.1
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
xclock-02.domain .ANT1.           1 u   26   64  377    4.478   -1.348   4.283
xclock-01.domain .ANT1.           1 u   21   64  377    3.993  -37.388   4.345

Lol Phirae

Re:Loadbalancing NTP serveru
« Odpověď #23 kdy: 10. 01. 2019, 10:41:51 »
K těm dvěma ntp serverům--- ale ntpd je oba označil jako lháře? ... Tušíte někdo kde může být zrada?

Lidi, co si takhle přečíst konečně tu dokumentaci, na kterou tady už několikrát bylo odkazováno? Jak u blbejch na dvorku, skutečně.

David1234

Re:Loadbalancing NTP serveru
« Odpověď #24 kdy: 10. 01. 2019, 10:46:44 »
Díky, již to tu zaznělo několikrát. Jde mi spíše o důvod proč jsou oba označení jako lháři, když vrací stejný čas (pokud je skript odkazovaný výše dostačující pro porovnání).

[root@server]# ./timecheck.py -v clock-01.domain.tld clock-02.domain.tld
Time received from clock-01.domain.tld = 1547113483 (Thu Jan 10 10:44:43 2019)
Time received from clock-02.domain.tld = 1547113483 (Thu Jan 10 10:44:43 2019)
Times match.

daemon

Re:Loadbalancing NTP serveru
« Odpověď #25 kdy: 10. 01. 2019, 10:58:35 »
Pokud neni provoz (presnost) ntp serveru bussiness critical, tak provozu ve virtualu nic nebrani.

V tom pripade trochu nechapu proc porizujete vlastni specialni HW na NTP sluzbu, kdyz muzete pouzit NTP z hranicniho routeru site LAN (nebo z internetu) nebo z libovolneho fyzickeho stroje (stroju) synchronizovaneho proti internetu

Protože to je, do značné míry, cvičná LAN. Proto se v ní vyskytují a dějí věcí, pro které třeba ani není praktické opodstatnění.

Mimochodem, teď vidím, že jsem poněkud přehlédl odstavec o virtualizovaném NTP v tom dlouhém příspěvku nahoře.

M.

Re:Loadbalancing NTP serveru
« Odpověď #26 kdy: 10. 01. 2019, 11:46:28 »
Ten skript jde na sekundy? Tak to není dostatečně.
Ne, ty dva NTP servery nehlásí stejný čas, dle toho ntpq -p. :-)
To reach=377 je bitová mapa v osmičkové soustavě počtu úspěšných pokusů kontaktovat NTP server, 377 znamená, že se 10x po sobě (v intervalu 64 sekund) povedlo z NTP získat informaci o času. Dle měření je zhruba stejné dopravní zpoždění od obou serverů (delay) a navíc oba servery vykazují skoro stejný jitter dat. Při započtení všeho jsou ty servery od sebe dost ujetý dle toho offset o cca 36 milisekund, což je "nechutné". Takže čert ví, který ten server je ten správný. Při tomto stavu je primárním kritériem (co jsem zkoušel) ten jitter, pokud by byl od jednoho výrazně větší, tak se přikloní k tomu druhému serveru rovnou, ale oba servery mají stejný jitter, sekundárně podobné dopravní zpoždění, tak neví ke komu se přiklonit a zahodil raději oba. Tady by asi pomohla nucená preference u nastavení peera (odkaz na true parametr dříve tady někde zazněl).

David1234

Re:Loadbalancing NTP serveru
« Odpověď #27 kdy: 10. 01. 2019, 12:23:25 »
Místo preference pomocí true jsem se rozhodl držet se doporučení - konfigurovat minimálně 4 ntp servery. Pořád mi ale vrtá hlavou ten rozdíl 36 milisekund, protože jde o hardwarové krabice (stejný výrobce i typ) které mají GPS anténu. Každá je fyzicky na jiném místě v Praze. Jak je možné že dávají tak rozdílný čas?

M.

Re:Loadbalancing NTP serveru
« Odpověď #28 kdy: 10. 01. 2019, 14:17:49 »
Nu, pokud je ten server, který se snažím synchronizovat, nějaký rozlítaný virtuál na desktopu, tak je možné, že něco takového naměří, pokud mu virtualizovaný vnitřní čas lokálně různě poposkakuje. To by se mšlo projevit létáním v delším časovém horizontu.
Jiná otázka je, jak skutečně je ten čas těch dvou GPS/NTP krabic od sebe. Pokud umí a můžeš, tak je nastavit jako vzájemný peer pro zálohu a uvidíš, jak uvidí sebe sama proti sobě a s jakou chybou.
Protože pro tak popsanou situaci je to asi moc.
Např:
Kód: [Vybrat]
# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
* NTP1            .MRS.            1 u  115  128  377    0.187    1.207   0.091
+ NTP2            .PPS.            1 u   40  128  377   12.779   -0.534   0.194
+ NTP3            .PPS.            1 u   50  128  377   15.208   -0.638   0.177
NTP1 je NTP s integrovanou GPSkou ležící vedle linux klienta (Intel Atom HW). NTP2 je NTP server s externí GPS cca 30 km na východ od něj a NTP3 je NTP server s externí GPS ležící cca 120 km západně, komunikačně je k oběma asi stejně daleko 2x kolem celé ČR, což odpovídá tomu delay. Rozdíl časů offsetem si ty dvě vzdálené NTP2 a 3 odpovídají, rozdíl proti lokální bude tím, že ty vzdálené NTP mají GPS externí a mezi GPS a NTP je několik převodů optika/metalika, kde není kompenzováno toto dopravní zpoždění v nastavení NTP serverů a taktéž od antény GPSky k vlastnímu přijímači je to kus cesty.
Pokud vezmu virtuální linux servery (KVM, virtuál i hostitel CentOS7, kde na tom fyzickém serveru běží desítky dalších virtuálů) a tento pomocí ntpd se syncuje proti dvěma v LAN umístěným NTP/GPS, tak to v nich vypadá takto:
Kód: [Vybrat]
# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
* 2NTP                .PPS.       1 u    7 1024  377    0.177   -0.483   0.034
+ 1NTP                .PPS.       1 u   37 1024  377    0.165   -0.484   0.041

Re:Loadbalancing NTP serveru
« Odpověď #29 kdy: 10. 01. 2019, 22:43:38 »
@M.: díky za názorná čísla :-)

Koukám že ten výsledek ve virtuálu nevypadá vůbec špatně... jitter 35-40 mikrosekund. Hezké.

A ten první výpis, kde je záporný offset asi půl milisekundy... pokud by tam bylo v sérii několik relativně pomalejších opto-převodníků, tak by to snad i mohlo něco vysvětlovat. Kabeláž od GPS antény k přijímači bych nepodezíral, protože 5 ns na metr, a těch metrů anténního svodu nebude moc. I kdyby stometrový svod, pořád jsme na 500 nanosekundách, to je o tři řády míň než ta cca půl milisekunda.
Ale jestli je tam dopravní zpoždění nějakých 12 ms, tak by tam mohla být cca půl ms asymetrie (ntpd počítá se symetrickým přenosovým zpožděním). Mimochodem si myslím, že by to asi šlo i dokompenzovat - třeba argumentem "bias" na řádku v ntp.conf?

 

reklama