Ntpd excessivement inexact

J'ai configuré ntpd (Meinberg ntp-4.2.6p5@london version pour Windows sur un client Windows 7) avec un tas de servers proches sélectionnés pour des time de ping bas (généralement 10-20 ms de ping). Cependant, il semble que mon horloge ne soit exacte qu'à 100 ms ou less et qu'elle ne s'améliore pas avec le time. J'aurais pensé que cela peut être beaucoup plus précis que le time de ping, c'est décevant. Comment le faire fonctionner mieux?

ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== +pool-test.ntp.o 216.218.254.202 2 u 259 1024 17 12.920 -106.39 111.972 +palpatine.steve 208.201.242.2 3 u 239 1024 17 16.959 -102.84 112.056 +grom.polpo.org 127.67.113.92 2 u 259 1024 17 17.362 -184.43 74.468 +paladin.latt.ne 204.123.2.72 2 u 378 1024 3 24.211 -106.97 61.825 +public-ntp1.iso 204.13.164.164 3 u 259 1024 17 33.080 -100.17 65.970 +nist1.symmesortingc .ACTS. 1 u 214 1024 17 17.548 -108.30 111.951 *nist1-sj.ustimi .ACTS. 1 u 245 1024 17 21.826 -111.02 63.313 

Comment la gigue et le décalage peuvent-ils être beaucoup plus importants que les retards? Etre éteint de 100 ms lorsque le time de ping est de 12 ms semble ridicule, est-ce que je lis ce problème?

En fait, je ne suis pas sûr que ntp fasse quoi que ce soit pour changer mon horloge – il semble avoir un time, mais pas nécessairement tout régler . Comment puis-je vérifier?

Quelques infos supplémentaires:

 ntpdc> sysinfo system peer: nist1-sj.ustiming.org system peer mode: client leap indicator: 00 stratum: 2 precision: -11 root distance: 0.02182 s root dispersion: 0.15431 s reference ID: [216.171.124.36] reference time: d4dae2b5.3c32ce54 Fri, Mar 1 2013 0:17:57.235 system flags: auth monitor ntp kernel stats jitter: 0.045776 s stability: 0.000 ppm broadcastdelay: 0.000000 s authdelay: 0.000000 s more "c:\Program Files (x86)\NTP\etc\ntp.drift" 192.049 more "c:\Program Files (x86)\NTP\etc\ntp.conf" driftfile "C:\Program Files (x86)\NTP\etc\ntp.drift" server nist1.symmesortingcom.com iburst server nist1-sj.ustiming.org iburst server 149.20.68.17 iburst server 173.230.144.109 iburst server 65.19.178.219 iburst server 204.2.134.162 iburst server 173.230.144.109 iburst server 207.115.64.229 iburst 

Idéalement, je veux un time qui ne se situe pas à plus de 50 ms de la médiane des servers configurés, si jamais il est plus loin, je le souhaite. Existe-t-il une option de configuration que je peux définir qui ferait que ntp fasse cela?

Jitter (aka dispersion dans le NTP plus ancien) peut et va varier beaucoup au fil du time. Surtout si vous avez une configuration où la connection entre vous et le server NTP est congestionnée. Vous devrez exécuter "ntpq -p" fréquemment (à propos de chaque "sondage" secondes) pour surveiller la gigue, ou allumer le file de performance ("statsdir" et "statistics" dans le file ntp.conf).

http://www.ntp.org/ntpfaq/NTP-s-sw-clocks-quality.htm http://www.ntp.org/ntpfaq/NTP-s-trouble.htm

Idéalement, je veux un time qui ne se situe pas à plus de 50 ms de la médiane des servers configurés, si jamais il est plus loin, je le souhaite. Existe-t-il une option de configuration que je peux définir qui ferait que ntp fasse cela?

NTP ne fonctionne pas de cette façon. Il choisit un server de votre list, le marque avec '*' (astérisque, aka source de time de reference) dans la première colonne de la sortie 'ntpq -p' et tente de le suivre. Dans le cas où la source de time de reference est devenue inaccessible, elle retombera à l'un des servers '+' (candidats qualifiés).

Je suggère:

  1. Ne pas utiliser iburst sur chaque server
  2. Choisir votre meilleur server, en utilisant iburst à ce sujet et en le marquant avec la preference, c'est-à-dire "server tick.example.com iburst préfère".
  3. Seuls les 3 servers fermés à la main.
  4. Plus d'utilisation des noms DNS du pool régional (tel que [0-3] .us.poo.ntp.org) pour le rest.
  5. Disque pour au less 4 servers de reference, mais pas plus de 9.
  6. Ne configurez jamais une ligne "server 127.127.1.0" (aka local clock) ou "fudge".

Par défaut, le choix "slew" vs "step" est de 128 ms. Si le décalage horaire est> 128 ms, il tombera plutôt que de se détruire. Voir le parleur "-x" de "ntpd" (qui ne devrait jamais être utilisé à less que vous ayez un logiciel qui s'effondre si l'horloge est en marche).

En plus de "ntpq -p", vous pouvez également regarder "ntpdc -c loopinfo".

NTP a été conçu pour get un time précis dans les 1s, sur presque n'importe quel réseau. Donc, à cet égard, 100 ms fonctionne correctement. Dans l'utilisation actuelle, NTP maintient généralement le time dans les 20ms sur presque n'importe quel matériel, et 5-10 ms sur le matériel avec un RTC stable.

Si votre server est continuellement désactivé par des nombres cohérents (par rapport à ses pairs), il est probable qu'il ait beaucoup de jitter dans son RTC. NTP pourrait compenser cela en battant ses pairs pour constamment get le «bon moment». Cependant, cela n'est pas recommandé et n'est pas très courtois pour ceux que vous regardez.

NTP ne "définit" pas l'horloge (par défaut). Il "tourne" l'horloge, ce qui le fait fonctionner un peu plus vite ou plus lentement jusqu'à ce que l'horloge frappe un time cible. Le taux de returnnement est ensuite réajusté pour compenser la "dérive" (le montant NTP a calculé que le RTC est rapide ou lent par rapport aux pairs).

De plus, je suis d'accord avec toutes les recommandations de la réponse de tgharold.