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):
# 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ů:
# 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):
# 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:
# 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):
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:
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:
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...
39 Odpovědí
10859 Zhlédnutí