Loadbalancing NTP serveru

[M.]

Nu, také mě to překvapilo, že to v těch virtuálech se na nich drží evidentně v desítkách us. Ale vysvětlení asi je, že to je rok starý HW a přestože je tam aktivně živých 20 virtuálů, tak počet fyzických jader cca odpovídá alokovanému počtu virtuálních CPU, takže se virtuál drží svého fyzického jádra a jede to takhle krásně ve virtuálu a taktéž na fyzickém HW pod tím (24 fyzických jader, virtálních 31, CentOS7 podklad i virtuál, KVM).

Pokud se podívám do racku vedle na historický HW, co má tak 7 let odslouženo, kde je 16 fyzickéch jader a o které soupěří aktivně běžících cca 30 virtuállů (podklad CentOS5, KVM, virtuály Slackware 10), tak už to je o řád horší (oba stejné NTP+externí GPSky v rámci LAN, 2NTP je jen o dva switche dál):

Kód: [Vybrat]

# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
* 2NTP          .PPS.            1 u   12 1024  377    0.244    0.817   0.664
+ 1NTP          .PPS.            1 -    8   64  377    0.224    0.062   0.460
A jak ta zátěž začne stoupat, tak to jde do kytek, lokalita na opačné straně ČR, 12 fyzických jader o které soutěží živých 50 virtuálů s CentOS6 podklad, KVM, virtuály Slackware 10, Zdrojem času jsou 3 NTP v LAN, dva sdílí jednu GPSku (NTP30 a NTP31), třetí ji má integrovánu:

Kód: [Vybrat]

# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+ NTP30          .PPS.            1 u   68  128  377    0.608   52.751 113.245
x NTP31          .GPS.            1 u   78  128  377    0.460  -122.04 126.707
* NTP32          .PPS.            1 u   78  128  377    1.869   56.161 114.396
To už odpovídá tomu, jak to ukazoval tazatel s těma dvměa NTP/GPS na dvou koncích Prahy. I zde je to rozlétáno a občas to některý NTP server vyhodí. Občas jsou čísla i horší, často i lepší. Přitom odjinud jsou ty 3 zdroje vidět v jedné lajně, pokud je to nazatížený stroj.

K tomu rozdílu půl ms u NTP ze tří lokalit, tak také souhlasím, že to je spíše dopad asymetričnosti linek a vlivu delay linky. Mnohem menší dopad má, že GPS není integrována v NTP a je tak od ní delší rozvod PPS s převodníky. Protože není nad jednoduchý pokus, že si v té jedné lokalitě připojím i něco s integrovanou GPS (NTP30-NTP32 odpovídá tomu výpisu výše i ze stejného času):

Kód: [Vybrat]

# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
- NTP1           .MRS.            1 u  170  256  377    0.168   -0.505   0.467
* NTP2           .PPS.            1 u  101  256  377   12.818   -1.821   0.467
+ NTP30          .PPS.            1 u  104  256  377   15.083   -2.009   0.585
+ NTP31          .PPS.            1 u  160  256  377   15.771   -2.695   1.034
+ NTP32          .GPS.            1 u  161  256  377   15.029   -1.812   0.526

Takže je vidět i stádovitost vyhodnocení shluku, kdy už NTP dává přednost vzdálenému zdroji, jehož jitter, delay a ofset je nejlepší z toho shluku a odmítne lokální zdroj o rack vedle (NTP1 je M500/GPS). NTP2 je těch 120 km západ (M300/RDT a ext GPS167), NTP30 až NTP31 je 30 km východ, komunikačně o něco dále, než ten západ, přitom NTP30 (M300/GPS s použitým ext PPS, protože interní GPS kaput) a NTP31 (M300/RDT) mají společnou GPS167, jen do NTP30 je to 30 metrů PPS rozvodu a do druhého 3/4 km rozvodů a asi šesti převodů metalika/sklo cestou. NTP32 je s integrovanou GPS (M300/GPS), tyhle tři leží u sebe v kruhu cca 1 km. Všude je cca 20~40 metrů koaxu mezi anténou a GPS.
Takže ten offset dle toho opravdu padá spíše na nedokonalost IP trasy, než těch lokálních rozvodů. Biasem by to šlo asi poštelovat, pokud by se mi neměnil moc charakter vytížení IP tras, ale není k tomu asi reálný důvod, jen jsem si to zkusil, jak se to cca chová. :-)

[Reklama]

[František Ryšánek]

@M. : ta poslední tabulka je boží :-) Tím Vás nechci nijak poňoukat k dalšímu popisování detailů Vaší sítě, myslím že jich bylo až dost... Vaše závěry jsou přesné. Já bych snad jenom zdůraznil, že je z toho hezky vidět, jak snadno by se mohlo stát, že partička upstream serverů, které mají offset zatížený shodnou systematickou chybou (sdílené úzké hrdlo v konektivitě s asymetrickou zátěží?) může přehlasovat objektivně mnohem přesnější blízký zdroj času :-)

Ony ty podrobnosti skutečně vyplavou na světlo až ve větší množině upstream serverů. Mimochodem všechny servery ve Vaší konfiguraci mají záporný offset. A ta "shluknutá skupina" co vyhrála hlasování má ofset asi o 1.5 ms zápornější než nešťastný outlier. Což by podle mého mělo znamenat, za jinak stejných okolností (pokud se asymetrie na linkách v čase nějak nezmění) že se "náš" ntpd bude snažit ten offset vynulovat postupným doladěním lokální časové základny. Tzn. v ustáleném stavu by "skupina co vyhrála hlasování" skončila rovnoměrně rozmístěná okolo ofsetu 0 a nešťastný NTP1 by skončil s reportovaným ofsetem asi +1.5 ms.

Taky jsem se sám ještě trochu poučil četbou dokumentace. Konkrétně jsem se napřed zajímal o přesný význam těch znamének na začátku řádku NTPq. (Popisuje to asi třetí HTML tabulka od uvedeného relativního odkazu.) Vím dávno, že hvězdička na začátku znamená "vítěz" a plus na začátku znamená "finalista - účastník váženého průměru", ale co znamená třeba mínus? To je ten co musel z kola ven? No a zjistil jsem, že "outlier" (znaménko mínus = Váš případ) není totéž jako falseticker (znaménko "x"). Ten ověřovací a shlukovací algoritmus je totiž dvoukolový.

V prvním kole (tzv. clock select algorithm) se nahrubo oddělí zrno od plev. Vyházejí se upstream servery, jejichž offset je větší než polovina round-tripu + směrodatná odchylka jitteru.

V druhém kole (tzv. clock cluster algorithm) dojde na jemnější shlukování - a outlier je server, který se dostal do druhého kola, ale jeho "interval pravděpodobných hodnot" (střední hodnota ofsetu +/- směrodatná odchylka jitteru) stojí mimo většinový shluk. A právě toto se stalo nejbližšímu serveru na stratu 1 :-D

Mám experimentálně nepotvrzený dojem, že rozdíl mezi oběma případy (fázemi vyhodnocení) bude v účinku klíčového slova "prefer". Jasný falseticker bude vyloučen i v případě, že má v konfiguraci slovo "prefer". Ale prostý outlier by s "prefer" argumentem patrně zvítězil :-)

Přiložím jeden screenshot. Zajímavé je, že lokální rádiem řízené hodiny nemají znaménko "o" (PPS peer), ale prázdné pole " " - což podle tabulky znamená "peer invalid". Tak mám dojem, že jsem ten screenshot típnul příliš brzy po startu stroje - ono chvíli trvá, než je refclock driver "spokojený". Patrně vstupní signál napřed chvíli sleduje a hledá případné nekonzistence, a ostatně jádro ntpd se refclock driveru taky ptá s delší periodou než 1/s. Nebo tam mají Meinbergové pod kapotou něco čemu nerozumím. Kromě toho se jednalo o hodně nový firmware na hodně starém hardwaru... A kromě toho dnešní Meinbergovic firmware už NEobsahuje dva pseudo-samostatné refclock drivery: pro ToD na sériovém UARTu driver "parse" + zvlášť PPS refclock 0, ale jenom jeden driver, který má podporu PPS integrovanou. Takže názvoslovně už nejedná o čistý PPS refclock. Hmm... na tohle se asi ještě zaměřím. Brzy bude příležitost.
Vlastně jsem chtěl ještě dodat, že interní GPS/PPS refclock má u Meinbergů (a zřejmě i jinde) vždycky právě prefer keyword. Resp. samostatný PPS refclock míval tradičně nějaké úplně specifické zacházejí, jako že "PPS má vždycky pravdu a vždycky offset 0".

[Filip Jirsák]

Mám experimentálně nepotvrzený dojem, že rozdíl mezi oběma případy (fázemi vyhodnocení) bude v účinku klíčového slova "prefer". Jasný falseticker bude vyloučen i v případě, že má v konfiguraci slovo "prefer". Ale prostý outlier by s "prefer" argumentem patrně zvítězil :-)

To dává smysl. Volbou prefer správce dává najevo, že daný server je v něčem lepší, když všechno funguje tak jak má. Nelze ale zaručit, že to tak bude navždy, že ten server někdy v budoucnu kvůli nějaké chybě (ať už serveru nebo na trase) začne poskytovat špatná data. Takže vyřazování falsetickerů musí dělat software průběžně, protože správce to nemůže stihnout zachytit včas. Do druhého kola ale už postoupí jen kandidáti, kteří by měli být v pořádku a už jde jenom o to vybrat toho aktuálně nejlepšího – a tam dává smysl ruční zásah správce, který může mít informace, které ntpd není schopno zjistit.

[M.]

Ano, "prefer" by mělo naznačit, co si přeji používat jako prioritní zdroj, který prošel prvním kolem výběru. Kdežto "true" je ještě drsnější, tím se snažím přebít zcela i ověřování spolehlivosti/stability.
Ale pokud jsem to pochopil správně, tak to mám zkusit. :-) Takže s pomocí soudku rumu, ať to lépe ubíhá....
Jak dám "prefer" na ten NTP1, tak dle očekávání se stane preferovaný zdroj a snaží se ho to sledovat, jak je ten zdroj blíže a stabilnější, tak se i ustálí hodnoty z dalších vzdálených zdrojů (ale něco bude i na vrub menšího víkendového zatížení IP tras):

Kód: [Vybrat]

# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
* NTP1            .MRS.            1 u  111  128  377    0.182   -0.056   0.076
+ NTP2            .PPS.            1 u    3  128  377   11.231   -0.086   0.068
+ NTP30           .PPS.            1 u   61  128  377   13.699   -0.335   0.121
+ NTP31           .PPS.            1 u   80  128  377   14.300   -0.306   0.317
+ NTP32           .GPS.            1 u   16  128  377   13.594   -0.311   0.071

Pokud to zkusím rozbít, že NTP1 má jen jako zdroj vnitřní referenci z GPS (žádný externí zdroj/NTP), stáhnu dobu platnosti nesync GPS (NTP Trusttime MRS=10sec) a vynutím cold boot GPSky a reboot CPU modulu, tak je vidět, že když to hlásí unsync stav (statum 16), tak se přepne na něco z dalších zdrojů:

Kód: [Vybrat]

# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
  NTP1            .INIT.          16 u   22  128  360    0.184    0.626   0.104
* NTP2            .PPS.            1 u   87  128  377   11.262    0.502   0.407
+ NTP30           .PPS.            1 u   32  128  377   13.569   -0.122   0.248
+ NTP31           .PPS.            1 u   29  128  377   14.325    0.021   0.574
+ NTP32           .GPS.            1 u   98  128  377   13.465    0.572   0.455
Když se pak ntpd rozjede a GPS pozdržím pár dalšíma cold rebooty, tak se chytne ntpd interní reference a přejde na stratum 12, jak má nastaveno, tak už ho to "prefer" přitáhne klienta zpět (ale asi pomáhá, že dost udrží ta interní reference v té M500):

Kód: [Vybrat]

# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
* NTP1            127.0.0.1       12 u   81  128  340    0.184    0.626   0.111
+ NTP2            .PPS.            1 u   18  128  377   11.262    0.502   0.657
+ NTP30           .PPS.            1 u   89  128  377   13.569   -0.122   0.185
+ NTP31           .PPS.            1 u   87  128  377   14.325    0.021   0.432
+ NTP32           .GPS.            1 u   28  128  377   13.585   -0.106   0.319
A až se to pak rozjede a přejde to na referenci z GPSky, tak to na moment z NTP1 odpadne (asi to trochu v té chvíli poskočí) a po chvíli se to na NTP1 poctivě vrátí a tam už to pak drží, pokud do toho nehrabu:

Kód: [Vybrat]

# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
* NTP1            .MRS.            1 u   65  256  377    0.185    0.195   0.060
+ NTP2            .PPS.            1 u   81  256  377   11.269    0.127   0.105
+ NTP30           .PPS.            1 u  138  256  377   13.590   -0.050   0.072
+ NTP31           .PPS.            1 u  160  256  377   14.134    0.112   0.568
+ NTP32           .GPS.            1 u   90  256  377   13.552   -0.035   0.089
Z toho plyne, že pokud na nějaký upstream si dám "prefer", tak to má být něco, co by mělo mít vždy nějaký rozumný čas k dispozici, jinak mi to může slušně ujet, než odchylku přebije ten shlukový algoritmus a vyrazí to z 1. kola selekce pro nesmyslnost. :-)

Add nastavení uvnitř Meinberga - asi ve všech (kde jsme do toho nehrabal :-) ), tak mají na PPS/GPS vstupu natvrdo dáno současně prefer i true a osmi sekundový interval braní dat (min/maxpool 3):

Kód: [Vybrat]

server  127.127.8.0 mode 151 prefer  minpoll 3 maxpoll 3 true  # UNI Erlangen with PPS

K tomu screen shotu - dle výstupu "fpc" v horní části, tak to hlásí, že GPS je ještě v COLD BOOT stavu. Pokud jsem postřehl, tak po power on nedává PPS, dokud se GPS nechytne (respektive PPS asi z GPS chodí, ale ntpd je ignoruje), takže ntpq nehlásí stav "o" u toho GENERIC asi oprávněně (mě se to většinou chytá kolem 800~830 sec po cold bootu s anténou s plným výhledem). Pokud je WARM/COLD BOOT vyvolán za běhu, tak to PPS dává(akceptuje), pokud neuplyne doba důvěryhodnosti nesynchronizované GPS (defaultně tam mají 4 dny: fudge   127.127.8.0 time2 345600     # trust time value ).
Protože když je to syncnuté (a chytí se to na první pulz ke kterému jsou sériová data se sync příznakem), tak s interní GPS:

Kód: [Vybrat]

NTP1 ~ # ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
oGENERIC(0)      .MRS.            0 l    2    8  377    0.000   -0.001   0.004
Kde je externí zdroj PPS plus sériový string:

Kód: [Vybrat]

NTP31 ~  # ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+GENERIC(0)      .DCFa.           0 l   11   16  377    0.000    0.000   0.002
oPPS(0)          .PPS.            0 l    6   16  377    0.000   -0.002   0.002
Ale asi jsme už dost přečerpali původního tazatele. :-)

Hm, jen si budu muset dobádat, proč mi na externí výstupy GPS modulu chodí sekundové pulzy v nesync stavu, přestože to mám zakázáno (Clock / GPS Clock / Enable Outputs / Pulses : If Sync). Nebo to tam někdo zase celé předrátoval a chodí zo z nějakých přesýpacích hodin...

[František Ryšánek]

@M.: hezky...
V tom prvním výpisu mě překvapuje, kam zmizel ten offset okolo 1.5 ms.
Protože round-trip delaye jsou jenom nepatrně nižší, než v předchozím výpisu (provoz přes den).
Případně by bylo zajímavé vědět, kolik z toho delaye je "stabilní základ" a kolik jde na vrub prodloužení front při silnějším provozu (potenciálně asymetrickém).
Přijde mi nepravděpodobné, že by ten rozdíl v delayích zmizel prostě jenom nastavením "prefer" objektivně nejbližšímu upstream serveru.

Cold boot má trvat v optimálním případě asi 12 minut, protože tak dlouho trvá přijetí úplného almanachu z družic (pokud v příjmu nejsou chyby). Meinberg nepodporuje stažení almanachu z Internetu (svého druhu assisted GPS, pokud se nepletu). Následuje "warm boot", který už může být docela rychlý - pokud se nepletu, v průběhu (nebo až na konci?) warm bootu už má přijímač poziční fix a čas. V zásadě se ještě čeká na konstalaci s použitelným DOP (tuším pod 2.5) = družice na "kolmých" směrech, aby se minimalizovala trigonometrická chyba v "průniku kulových ploch". V momentě kdy toto nastane, rozsvítí se stavová kontrolka GPSky zeleně. Pro potřeby NTP je to vše. Pokud je v systému PTP grandmaster, tak se ještě čeká na event "oscillator adjusted" - zmíněný oscilátor je sice v přijímači GPS, ale PTP grandmaster čeká na jeho plný závěs, teprve pak totiž začne v protokolu PTP deklarovat přesnost "<100 ns".

Takže oni Meinbergové cpou GPS refclocku dokonce "true"? No... ono to dává smysl, když přidat alternativní upstream NTP servery do konfigurace ntpd jde u MRS sestav už jenom oklikou, a primárním způsobem závěsu na upstream NTP server je cesta skrz MRS = podle záložního NTP se v případě výpadku příjmu družic (volně) dolaďuje oscilátor přijímače, o čemž ntpd na x86 CPU kartě nemá ani potuchy. Z mého pohledu je to škoda, padají tím totiž výhody toho "dvoukolového prosévacího algoritmu" (MRS tohle neumí) - v odůvodněných případech lze přesto upstream ntp servery do ntp.conf dodat ručně. Tzn. je dobré o těchto nuancích vědět a umět si vybrat. Ještě zkusím zjistit, jestli lze odstranit "true".

A ještě:
> Clock / GPS Clock / Enable Outputs / Pulses : If Sync
To se podle mého netýká interní PPSky pro CPU kartu. Toto se týká programovatelných pulzních výstupů, které jsou samostatně vyvedené ze šasi (na konektory na panelu). Resp. mohou být - jedná se o factory option. Tyto výstupy umí krmit přímo Meinbergovic karta přijímače, lezou z jejího FPGA. (V modulárních IMS sestavách se dále vyskytují přídavné karty jako CPE180, které mají vlastní podružný oscilátor a FPGA a programovatelné výstupy.)

[Reklama]

[František Ryšánek]

Hmm... ještě jednou koukám na popis "clock select algoritmu" a řekl bych, že ten můj popis opsaný z prvního odstavce dokumentace zřejmě nesedí.

V prvním kole (tzv. clock select algorithm) se nahrubo oddělí zrno od plev. Vyházejí se upstream servery, jejichž offset je větší než polovina round-tripu + směrodatná odchylka jitteru.

Odkazovaný HTML dokument mi přijde interně nekonzistentní, nebo přinejmenším hrubě zkratkovitý. Jsem z toho daněk.

[František Ryšánek]

V tom prvním kroku se napřed provede základní "sanity checking" nakonfigurovaných asociací, a následně se hledá "interval překryvu pro maximální počet asociací". Kdo se tohoto maximálně četného překryvu neúčastní, stane se falsetickerem...? Přesné blízké zdroje času dostanou pro potřeby tohoto algoritmu "rozhodnutím strany" určitý minimální rozptyl ("mindist", default 1 ms) aby získaly lepší "koaliční potenciál" a nevypadávaly rovnou jako falsetickers.

No a ve druhém kroku se jedná opět o jakýsi clustering, ale tentokrát nikoli prostým překryvem, ale iterativním odlupováním nejodlehlejších jedinců... dokud nenastane ukončující podmínka. Pokud správně chápu popis.

Poznatky ohledně "prefer" a "true" myslím platí beze změny.

[M.]

Aha, že by si ani autoři NTPD nebyli zcela jisti, jak to vlastně funguje? :-)

Ale k tomu, že to přidání prefer na NTP1, že se to celé uklidnilo, tak to nebylo tím, ale víkendovým komunkačním klidem na IP trasách. Když jsem prefer z NTP1 vyhodil a nechal to být, tak dle očekávání preferovaný odcestoval na vzdálenou grupu, ale offset/jitter/delay byl v podstatě stejný, jak s prefer na NTP1:

Kód: [Vybrat]

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+ NTP1           .MRS.            1 u   34  256   17    0.167   -0.069   0.007
* NTP2           .PPS.            1 u   37  256   17   11.477   -0.097   0.069
+ NTP30          .PPS.            1 u   32  256   17   13.732   -0.291   0.083
- NTP31          .PPS.            1 u   32  256   17   14.733    0.142   0.194
+ NTP32          .GPS.            1 u   29  256   17   13.727   -0.219   0.076
Když pak došlo k přetížení komunikačních tras pro vynucený traffic, tak je vidět, jak se u vzdálených NTP rozletěl delay a další, ale zvolen zůstal stejně "nejlepší" vzdálený NTP server a lokální NTP1 šel dokonce do outliner:

Kód: [Vybrat]

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
- NTP1           .MRS.            1 u  683 1024  377    0.253    0.134   0.011
+ NTP2           .PPS.            1 u  937 1024  377   23.953   -5.955   6.722
* NTP30          .PPS.            1 u  954 1024  377   13.742   -1.752   1.702
+ NTP31          .PPS.            1 u  946 1024  377   23.969   -4.364   4.484
+ NTP32          .GPS.            1 u  175 1024  377   23.168   -4.573   4.514
Po pominutí přenosu se to ustálilo zpět, prefer stále vzdáleně:

Kód: [Vybrat]

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+ NTP1           .MRS.            1 u  969 1024  377    0.207    0.876   0.256
* NTP2           .PPS.            1 u  195 1024  377   11.405    0.706   0.230
- NTP30          .PPS.            1 u  214 1024  377   14.174   -0.866   0.030
+ NTP31          .PPS.            1 u  206 1024  377   15.319    0.922   0.182
- NTP32          .GPS.            1 u  455 1024  377   13.746    0.557   0.060
Takže podobně ucpané linky dokáží asi celkem to pak vyosit a přitáhnout úplně někam jinam. :-(

Add to, že Meinbergové dávají prefer i true u refclocku, tak u toho M500 s MRS (firmvare v6) je to asi pochopitelné, opravdu přidané externí NTP servery to nedá do ntp.conf, ale nějak si to šušní v té MRS částí (toho jsme si doteď ani nevšiml, z toho webksichtu to není na první pohled patrné, dostanu je tam leda přes textové "Edit Additional NTP Parameters").
Pokud se podívám na M300/GPS s v6 firmware, tak je tam prefer i true:
server  127.127.8.0 mode 151 prefer  minpoll 3 maxpoll 3 true  # UNI Erlangen with PPS
Ale přidané NTP servery do strká do ntp.conf a řeší to ntpd klasicky.
Pokud vermu M300/RDT s v6 firmware, tak to je stejné, použito prefer i true pro externí časový normál:
server  127.127.8.0 mode 151 prefer  minpoll 3 maxpoll 3 true  # UNI Erlangen with PPS
taktéž externí NTP servery obsluhuje klasicky ntpd.
Mám i pár M300/RDT ještě na v5 firmware, tam je použité jen prefer (a jiný stirng formát):
server  127.127.8.0 mode 130 prefer  minpoll 4 maxpoll 4  # Meinberg Time String 9600/7E2 with PPS
Externí NTP klasicky obsluhované ntpd démonem (jinak ani nejde, ty M300/GPS a /RDT přeci jen mají jiný HW než M500 s MRS). Pohledemedo wekschichtů není nic, co by nastavitelnost true a prefer dovolovaly.
Je vidět, že to použití prefer a true asi prošlo historicky nějakým vývojem. :-)

[František Ryšánek]

@M.: díky za další podrobnou reakci :-)

Nepatrná grammar nazi korekce: ten co dostane v ntpq hvězdičku se oficiálně jmenuje "sys-peer" (ve shluku přesných kandidátů něco jako "čestný předseda"). "prefer" je fakt jenom argument v konfiguráku.

Na keyword "true" jsem se zeptal technické podpory. Vzhledem k tomu, jak je poslední týden zkouším z obtížných témat, odpověď možná nebude dneska ;-)

Tahle debata se mi strefila zrovna do nějakého pracovního úkolu, kde řeším distribuci času v nějaké rozsáhlejší WAN: na periferních lokalitách GPSkové NTP servery s backupem přes NTP na pár centrálních lokalit. "Prefer" keyword u lokálních GPS přijímačů vypadá jako hodně dobrá finta proti systematické asymetrii přenosového zpoždění u záložních NTP uplinků. Za normálních okolností lokální GPSka vyhraje volby i když s ostatními o fous nesouhlasí, ale není tím dotčeno její vyřazení jakožto falsetickera, pokud si začne moc vymýšlet (nesoulad se záložními NTP servery překročí jakousi hranici). V takové situaci si pak periferní lokality musí vystačit s přesností NTP over WAN, o kterém už víme, že může mít offset trochu zatížený asymetrií přenosových zpoždění - která závisí na zátěži ostatním provozem. Asi lepší než drátem do oka.

S tou asymetrií by možná trochu pomohla priorizace NTP provozu v queueingu na síťových elementech "na vstupu do úzkého hrdla" (což může a nemusí být problém v jiných ohledech, ať už se bavíme o L3 nebo o L2).

Kladivem na asymetrii je protokol IEEE1588 (PTP), pokud ho síťové elementy po cestě podporují (aktualizují pole "korekce" v PTP paketech). Tohle kladivo je bohužel docela drahé a jeho Best Master Clock Algorithm bohužel nedosahuje úrovně vychytralosti v třídění a kombinování více upstream zdrojů, kterou známe z NTP. On se bohužel PTP a jeho BMCA pohybuje s jitterem o tři-čtyři řády níž než NTP a asi tam při rozhodování hrají roli jiná hlediska, zejména rychlost konvergence, a třeba taky implementační jednoduchost klientů. Nemluvě o dosud probíhající evoluci PTP (a to "ve více vláknech" - viz ptp "profiles" a ani to zřejmě ještě není konec příběhu o babylónské věži).

[M.]

Ohledně toho úkolu - ano, vypadá to, že u klientů je použití prefer u deifnice toho lokálního NTP dobrou volbou. Dle pokusů za posledních pár dnů, tak když mám lokální NTP server s "prefer", tak si ten lokální NTP server udrží "sys-peer" ( :-) ) stav i v případě, kdy vzdálené servery drží pohromadě v jedné lajně, což je dobře (i když spoje k dalším přetížím a ujedou v jedné lajně s ofsetem/delay/jitter celkem daleko). Nepoveldeo se mi ucpáváním tras vychýlit vzdálené NTP tak, aby to na ně přešlo, pokud lokální hlásil něco lepšího, jak stratum 16. Tím pádem je ale nutno mít ten lokální NTP syncovaný i odjinud, než jen ta lokální GPSka, protože ho to udrží i v případě, kdy jede z lokálníhch hodin bez extenrí reference (pokud je nastavneo, že ji má propagovat jako stratum 12 a validní stav). To samozřejmě platí pro stav, že klienti jsou inteligentní plnotuční NTP klienti, pokud je to něco SNTP tupého, tak ten zkusí a pokud dostane sync odpověd z něčeho, tak ji použije a dál nebádá, že další NTP server trvdí zcela něco jiného...

Souhlasím, že je vhondéí míd UDP/123 trochu popostrčeno v řízení provozu, pokud mám technolohii, co to umí.

Nu, PTPv2 vnímám jako trochu něco jiného. Jednak u něj se moc nepočítá s WAN provozem, spíše jen LAN. A hlavně ho vnímám, že má zajistit, aby všichni kleinti v dané sítí měli pokud možno stejný čas proti jendomu jasně danému zdroji (případně i stejný refereční frekvenční normál, pokud je to včetně SyncE), proto je ten algoritmus výběru grandmastera dost jinak, než u NTP. U PTP chci mít stejný čas s grandmasterem (a často ten nemusí mít čas platný se zbytkem světa), kdežto u NTP se snažím inteligentně přiblížit světovému času u všech klientů, ale každý klient může být dle své regulace někam trochu ujet. Takže PTP je spíše evoluce časových rozvodů na bázi IRIGu a podobných, kde se u NTP něčím málo inspirovali. Implementačně a v počtu profilů je PTPv2 bordel na N-tou, to je fakt ke smíření. :-)