Řešení 1:
Vidím zde v odpovědích určitý zmatek. Pro začátek ntpclient , alespoň v -s režimu, nechová se jako úplný NTP klient, pouze odesílá a přijímá jeden paket , takže zde není "posledních 8 přijatých paketů". Ve skutečnosti vůbec neodhaduje svůj vlastní rozptyl.
Místo toho je hodnota, kterou tiskne, hodnota zvaná „root disperze“ (rootdisp) v paketu vráceném serverem, což je odhad celkového množství chyb/rozdílu mezi tímto serverem a správným časem. Způsob výpočtu je velmi jednoduchý:každý NTP server získává svůj čas buď z externích hodin (například rádia nebo GPS přijímače), nebo z jiného NTP serveru. Pokud server získává svůj čas z externích hodin, jeho kořenový rozptyl je odhadovaná maximální chyba těchto hodin. Pokud získá čas z jiného NTP serveru, jeho kořenová disperze je kořenová disperze daného serveru plus rozptyl přidaný síťovým spojením mezi nimi.
Jeden bod zmatku je, že zatímco ntpq a chrony zobrazují disperzi a kořenovou disperzi v sekundách, na což jsou lidé zvyklí dívat se, ntpclient to zobrazuje v mikrosekundách . Bez ohledu na to je hodnota 1217163 stále poměrně vysoká. Dobrý NTP server zná čas během několika milisekund; špatný během několika desítek nebo stovek milisekund. Ten váš vám říká, že jeho času lze věřit pouze v rozmezí +/- 1,2 sekundy.
Ve skutečnosti můžete stejně přimět ntpclient k synchronizaci na tento server předáním -x 0 nebo -t volba (v závislosti na verzi ntpclient), která zakáže kontroly NTP sanity. Pokud potřebujete pouze zhruba přesný čas (do několika sekund), může to stačit. Nicméně, ntpclient je docela rozumné v odmítání synchronizace s tak špatným serverem. Vaše ntpq výstup na stroji ubuntu ukazuje kolísání stovek milisekund pro všechny jeho servery, i když mají malé zpoždění, což naznačuje buď velmi nespolehlivou síť, spiknutí všech serverů, aby poskytovaly nepravidelný čas, nebo základní problém s měřením času na samotném serveru.
Také mě znepokojuje, že server 10.31.10.22 inzeruje refid LOCL (nedisciplinované místní hodiny), ale mají vrstvu 1. Obvykle jsou místní hodiny posunuty na vrstvu 10, takže se používají pouze jako synchronizační zdroj poslední instance, aby se stádo nerozdělilo. Buď je 10.31.10.22 špatně nakonfigurován a poskytuje špatné časy zbytku sítě, nebo je disciplinován nějakým programem mimo kontrolu NTP, aby byl správný čas, v takovém případě je chybná konfigurace jednoduše v tom, že propaguje kód LOCL refidovat; měl by být přepsán např. GPS nebo cokoli, co poskytuje svůj čas.
Řešení 2:
Jen částečná odpověď na otázku „Co je disperze?“:
Typická zpáteční cesta NTP:
client | | server
t1 |------->| t2
t3 |<-------| t4
Výsledkem jsou dvě hodnoty, offset (časový rozdíl mezi klientem a serverem) a zpoždění (podstatné pro dobu cestování sítí) s následujícími vzorci:
offset= ((t4 - t3) + (t1 - t2)) / 2
delay = (t4 - t1) - (t3 - t2)
Klient vybere aktuální offset z posledních 8 přijatých paketů a vybere ten s nejmenším zpožděním.
K výpočtu disperze se používá stejných 8 paketů provedením váženého průměru rozdílu těchto 8 offsetů vůči jednomu zvolenému v posledním kroku, kde je zpoždění použito jako váhový faktor, což dává větší váhu menším zpožděním. Je to měřítko pro "rozložení" hodnot a používá se k výpočtu kvality časového serveru, zejména pokud máte na výběr z více.
Řešení 3:
Váš rozptyl a zešikmení jsou obrovské, je zde velmi velký posun oproti místním hodinám. Měli byste porovnat offsety s místním date a nastavte hodiny ručně.
Spusťte ntpd a ukažte ntpq -p od hostitele využívajícího všechny rovnocenné servery. Vybere ty lepší.
Řešení 4:
Podle této dokumentace společnosti cisco "disperze , uváděný v sekundách, je maximální časový rozdíl hodin, který byl kdy pozorován mezi místními hodinami a hodinami serveru." U serverů ntp, které nejsou zcela rozbité, by nikdy nemělo dojít k vysokému rozptylu. Jediný možný scénář je, když váš klient spustí ntp a zatím má k dispozici pouze místní hodiny. A dokonce i tak vysoký rozptyl, jaký uvádíte, odpovídá hodinám, které jsou posunuté o více než dva týdny .
Mělo by stačit zajistit, aby místní hodiny nebyly na začátku příliš daleko (i několik hodin by bylo stále přijatelné), a to buď úpravou hodin (a dokonce i data!) v BIOSu nebo zadáním ntpdate jednou před spuštěním ntpd na klientovi.