Hodnota ntpstat zobrazí se po "time correct to within" je kořenová disperze + kořenové zpoždění / 2. ntpq -p nezobrazuje běh "root disperze" ntpq -c rl místo toho.
Bez ohledu na to je jasné, že hlavním zdrojem nepřesnosti je spíše rozptyl než zpoždění (které je pouze 0,964).
Rozptyl je "nominální chyba vzhledem k primárnímu referenčnímu zdroji." Krátce jsem si prohlédl NTPv4 RFC a je v něm to, co říká:
Disperze (epsilon) představuje maximální chybu vlastní měření. Zvyšuje se rychlostí rovnající se maximální disciplinované toleranci systémové frekvence hodin (PHI), typicky 15 PPM. 1 PPM se rovná 10^(-6) sekund/sekundu.
Chcete-li použít terminologii rrdtool, disperze není měřidlo, ale spíše počítadlo. Zobrazení velké hodnoty nemusí znamenat, že něco není v pořádku.
Bohužel jsem nebyl schopen porozumět ntp algoritmu dostatečně dobře, abych viděl, jak toto číslo zmenšit. Všiml jsem si, že se tato hodnota občas resetuje. Nevím proč.
Důvod, proč jsem se ptal na výše uvedený hardware, je ten, že mnoho zařízení GPS (vrstva 0, „kořenový“ zdroj) se připojuje k počítači, který pak funguje jako NTP server prostřednictvím sériové linky.
Sériová připojení mají často 1-5 ms jitter na lince kvůli signalizaci režie / čekání na přerušení. Proto předpokládám, že váš zdroj NTP čte ze sériového zdroje.
Existuje několik vylepšení, které můžete provést na sériovém připojení, abyste snížili jitter. Především deaktivace FIFO vám může přinést slušné výsledky.
http://support.ntp.org/bin/view/Support/KnownHardwareIssues#Section_9.1.5.http://www.febo.com/time-freq/ntp/jitter/index.html
Přesný čas do 5 ms JE SKVĚLÝ!!! 5 ms je 5/1000 sekundy. Cokoli pod 100 ms je snadno přijatelné pro cokoli jiného, než je malá hrstka situací, v takovém případě byste nepoužívali GPS, ale místní atomové hodiny a dvě externí referenční hodiny. S ntp poolem se dostaneme do 10 ms.