Solution 1 :
Je vois une certaine confusion dans les réponses ici. Pour commencer, ntpclient , au moins en -s mode, n'agit pas comme un client NTP complet, il envoie et reçoit seulement un paquet , il n'y a donc pas de "8 derniers paquets reçus". Il n'estime pas du tout sa propre dispersion.
Au lieu de cela, la valeur qu'il imprime est la valeur appelée "dispersion racine" (rootdisp) dans le paquet renvoyé par le serveur, qui est une estimation de la quantité totale d'erreur/variance entre ce serveur et l'heure correcte. La façon dont cela est calculé est assez simple :chaque serveur NTP obtient son heure soit à partir d'une horloge externe (par exemple un récepteur radio ou GPS), soit à partir d'un autre serveur NTP. Si un serveur obtient son heure d'une horloge externe, sa dispersion racine est l'erreur maximale estimée de cette horloge. S'il obtient son heure d'un autre serveur NTP, sa dispersion racine est la dispersion racine de ce serveur plus la dispersion ajoutée par le lien réseau entre eux.
Un point de confusion ici est qu'alors que ntpq et chrony affichent la dispersion et la dispersion racine en quelques secondes, ce à quoi les gens ont l'habitude de regarder, ntpclient l'affiche en microsecondes . Quoi qu'il en soit, une valeur de 1217163 est encore assez élevée. Un bon serveur NTP connaît l'heure en quelques millisecondes; un mauvais en quelques dizaines ou centaines de millisecondes. Le vôtre vous dit que son heure ne peut être fiable qu'à +/- 1,2 seconde.
Vous pouvez en fait faire en sorte que ntpclient se synchronise avec ce serveur de toute façon en passant le -x 0 ou -t option (selon la version de ntpclient), qui désactive les contrôles d'intégrité NTP. Si vous n'avez besoin que d'un temps à peu près précis (à quelques secondes près), cela peut suffire. Cependant, ntpclient est assez raisonnable en refusant de se synchroniser avec un si mauvais serveur. Votre ntpq la sortie sur la machine ubuntu montre une gigue de centaines de millisecondes pour tous ses serveurs, même s'ils ont un faible retard, ce qui indique soit un réseau très peu fiable, une conspiration de tous des serveurs pour fournir un temps irrégulier, ou un problème de chronométrage de base sur le serveur lui-même.
Cela m'inquiète également que le serveur 10.31.10.22 annonce un refid de LOCL (horloge locale indisciplinée) mais a une strate de 1. Habituellement, l'horloge locale est calée sur une strate de 10, de sorte qu'elle n'est utilisée que comme source de synchronisation de dernier recours pour empêcher un troupeau de se séparer. Soit 10.31.10.22 est mal configuré et fournit du mauvais temps au reste du réseau, soit il est discipliné au bon moment par un programme hors du contrôle de NTP, auquel cas la mauvaise configuration est simplement qu'il annonce le LOCL refid; il doit être remplacé par ex. GPS ou tout ce qui fournit son temps.
Solution 2 :
Juste une réponse partielle pour "Qu'est-ce que la dispersion ?" :
Un aller-retour NTP typique :
client | | server
t1 |------->| t2
t3 |<-------| t4
Cela donne deux valeurs, le décalage (la différence de temps entre le client et le serveur) et le délai (l'essentiel du temps de trajet sur le réseau) avec les formules suivantes :
offset= ((t4 - t3) + (t1 - t2)) / 2
delay = (t4 - t1) - (t3 - t2)
Le client sélectionne le décalage actuel parmi les 8 derniers paquets reçus, en choisissant celui avec le plus petit retard.
Les 8 mêmes paquets sont utilisés pour calculer la dispersion en faisant une moyenne pondérée de la différence de ces 8 décalages par rapport à celui sélectionné à la dernière étape, où le retard est utilisé comme facteur de pondération, donnant un poids plus important aux retards plus petits. C'est une mesure de la "propagation" des valeurs et utilisée pour calculer la qualité d'un serveur de temps, surtout si vous avez le choix entre plusieurs.
Solution 3 :
Votre dispersion et votre biais sont énormes, il y a un très grand décalage entre l'horloge locale et ce pair. Vous devez comparer les décalages avec le date local et régler l'horloge manuellement.
Lancez ntpd et affichez ntpq -p d'un hôte en utilisant tous les pairs. Il sélectionnera les meilleurs.
Solution 4 :
Selon la documentation Cisco, "dispersion , exprimée en secondes, est la différence d'heure d'horloge maximale jamais observée entre l'horloge locale et l'horloge du serveur". Avec des serveurs ntp qui ne sont pas totalement en panne, une dispersion élevée ne devrait jamais se produire. Le seul scénario possible est lorsque votre client initie son ntp et n'a jusqu'à présent que son horloge locale disponible. Et même dans ce cas, une dispersion aussi élevée que celle que vous signalez correspond à des horloges décalées de plus de deux semaines .
Il devrait suffire de s'assurer que l'horloge locale n'est pas trop éloignée au début (même quelques heures seraient encore acceptables), soit en ajustant l'horloge (et même la date !) dans le BIOS, soit en émettant ntpdate une fois avant de commencer ntpd sur le client.