[ntp] Écart de l'heure constaté sur 2 machines avec la même configuration
26 réponses
Francois Lafont
Bonjour à tous,
J'ai deux machines, une Squeeze et l'autre une Ubuntu Precise. Ce sont des OS différents mais je pense que, dans le cas présent, ça n'a pas d'importance. Sur les deux machines, j'ai installé le paquet ntp et j'ai mis la même configuration dans le fichier /etc/ntp.conf à savoir :
------------------------------------------------------------------
# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help
driftfile /var/lib/ntp/ntp.drift
# Enable this if you want statistics to be logged.
#statsdir /var/log/ntpstats/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
# You do need to talk to an NTP server or two (or three).
server ntp1.proxad.net
# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
# details. The web page <http://support.ntp.org/bin/view/Support/AccessRestrictions>
# might also be helpful.
#
# Note that "restrict" applies to both servers and clients, so a configuration
# that might be intended to block requests from certain clients could also end
# up blocking replies from your own upstream servers.
# By default, exchange time with everybody, but don't allow configuration.
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1
------------------------------------------------------------------
J'ai redémarré le service ntp sur les deux machines après modification de la configuration.
Au départ, juste après le redémarrage des services ntp, j'ai bien mes deux machines qui ont la même heure (à une dizaine de secondes près). Mais au bout d'un certain temps (pas très longtemps, à peine une heure ou deux), je me retrouve avec un décalage de l'heure entre les deux machines qui peut atteindre 20s voire 30s.
J'ai tenté aussi de mettre dans la configuration de ntp (des deux machines) 4 serveurs de temps (par exemple avec les {0,1,2,3}.fr.pool.ntp.org) mais j'ai aussi le même phénomène qui finit par se produire.
Dans mon esprit, ntp est un truc assez précis et je pensais que j'aurais deux machines à la même heure à la seconde près les doigts dans le nez.
Est-ce que j'en demande trop ?
Ou bien je ne fais pas ce qu'il faut au niveau de la configuration ?
delay trop grand ? As-tu essayé différents serveurs ? (Dans ma conf j'ai fr.pool.ntp.org, et ntpq donne comme refid ntp-p1.obspm.fr, avec un « delay » 2.404).
Bizarre, normalement fr.pool.ntp.org est un pool de stratum 2, donc ntp-p1.obspm.fr, qui est de stratum 1, ne devrait pas apparaître. Et fr.pool.ntp.org correspond à 4 IP en round robin, mais aucune ne pointe vers obspm. N'as-tu pas un ntp-p1.obspm.fr en dur qui traîne dans ta config ?
-- DW
* Lucas Levrel <lucas.levrel@u-pec.fr>
in fr.comp.os.linux.configuration:
delay trop grand ? As-tu essayé différents serveurs ? (Dans ma conf
j'ai fr.pool.ntp.org, et ntpq donne comme refid ntp-p1.obspm.fr, avec
un « delay » 2.404).
Bizarre, normalement fr.pool.ntp.org est un pool de stratum 2, donc
ntp-p1.obspm.fr, qui est de stratum 1, ne devrait pas apparaître. Et
fr.pool.ntp.org correspond à 4 IP en round robin, mais aucune ne pointe
vers obspm. N'as-tu pas un ntp-p1.obspm.fr en dur qui traîne dans ta
config ?
delay trop grand ? As-tu essayé différents serveurs ? (Dans ma conf j'ai fr.pool.ntp.org, et ntpq donne comme refid ntp-p1.obspm.fr, avec un « delay » 2.404).
Bizarre, normalement fr.pool.ntp.org est un pool de stratum 2, donc ntp-p1.obspm.fr, qui est de stratum 1, ne devrait pas apparaître. Et fr.pool.ntp.org correspond à 4 IP en round robin, mais aucune ne pointe vers obspm. N'as-tu pas un ntp-p1.obspm.fr en dur qui traîne dans ta config ?
-- DW
Damien Wyart
En très résumé, ce qui pose problème c'est qu'il s'agit de machines virtuelles ; parfois on n'a pas de problème (ça dépend notamment de l'outil utilisé pour virtualiser, par exemple avec Xen ça se passe bien en général, et ça dépend aussi du matériel), mais il est assez fréquent que NTP ne soit pas utilisable dans ce contexte.
Lors des premiers échanges, le message de départ n'indiquait pas qu'il y avait de la virtualisation, et j'avais du rater le message postérieur, qui le mentionnait.
> ~# cat /var/lib/ntp/ntp.drift > 500.000
> Et il signifie quoi ce 500.000 exactement ?
Il s'agit du décalage de fréquence entre la machine surveillée par ntpd et la source de référence ; c'est exprimé en PPM, voir les détails ici : http://www.ntp.org/ntpfaq/NTP-s-sw-clocks-quality.htm
Et si je ne me trompe pas, 500 est la valeur maximale, qui fait que ntpd va refuser de superviser l'horloge de la machine.
Avec les liens cités plus haut, on pourrait être tenté de "bidouiller" (voir par exemple http://0x657573.wordpress.com/2010/12/09/setting-up-an-ntp-gateway/ qui est assez gratiné :-)
- soit sur la clocksource du noyau invité - soit sur le paramétrage fin de l'outil de virtualisation (VirtualBox dans ton cas) - soit sur la config ntpd ("tinker panic 0", élimination de "fudge 127.127.1.0 stratum 10" mais en debian ça n'est pas par défaut, "tos maxdist" --- là ça devient très pifométrique) -> tout ça pouvant être combiné
-> idem, les items de cette liste peuvent être combinés.
J'ajoute une 4e bidouille qui est parfois mentionnée : effacer ntp.drift (qui sera recréé au démarrage suivant de ntpd) ; comme l'horloge de l'invité est instable, la valeur est parfois relativement faible et n'empêche plus ntpd de démarrer, mais ça ne garantit rien sur les démarrages suivants.
-- DW
En très résumé, ce qui pose problème c'est qu'il s'agit de machines
virtuelles ; parfois on n'a pas de problème (ça dépend notamment de
l'outil utilisé pour virtualiser, par exemple avec Xen ça se passe
bien en général, et ça dépend aussi du matériel), mais il est assez
fréquent que NTP ne soit pas utilisable dans ce contexte.
Lors des premiers échanges, le message de départ n'indiquait pas qu'il
y avait de la virtualisation, et j'avais du rater le message postérieur,
qui le mentionnait.
> ~# cat /var/lib/ntp/ntp.drift
> 500.000
> Et il signifie quoi ce 500.000 exactement ?
Il s'agit du décalage de fréquence entre la machine surveillée par
ntpd et la source de référence ; c'est exprimé en PPM, voir les
détails ici : http://www.ntp.org/ntpfaq/NTP-s-sw-clocks-quality.htm
Et si je ne me trompe pas, 500 est la valeur maximale, qui fait que ntpd
va refuser de superviser l'horloge de la machine.
Avec les liens cités plus haut, on pourrait être tenté de "bidouiller"
(voir par exemple
http://0x657573.wordpress.com/2010/12/09/setting-up-an-ntp-gateway/
qui est assez gratiné :-)
- soit sur la clocksource du noyau invité
- soit sur le paramétrage fin de l'outil de virtualisation (VirtualBox
dans ton cas)
- soit sur la config ntpd ("tinker panic 0", élimination de "fudge
127.127.1.0 stratum 10" mais en debian ça n'est pas par défaut, "tos
maxdist" --- là ça devient très pifométrique) -> tout ça pouvant être combiné
-> idem, les items de cette liste peuvent être combinés.
J'ajoute une 4e bidouille qui est parfois mentionnée : effacer ntp.drift
(qui sera recréé au démarrage suivant de ntpd) ; comme l'horloge de
l'invité est instable, la valeur est parfois relativement faible et
n'empêche plus ntpd de démarrer, mais ça ne garantit rien sur les
démarrages suivants.
En très résumé, ce qui pose problème c'est qu'il s'agit de machines virtuelles ; parfois on n'a pas de problème (ça dépend notamment de l'outil utilisé pour virtualiser, par exemple avec Xen ça se passe bien en général, et ça dépend aussi du matériel), mais il est assez fréquent que NTP ne soit pas utilisable dans ce contexte.
Lors des premiers échanges, le message de départ n'indiquait pas qu'il y avait de la virtualisation, et j'avais du rater le message postérieur, qui le mentionnait.
> ~# cat /var/lib/ntp/ntp.drift > 500.000
> Et il signifie quoi ce 500.000 exactement ?
Il s'agit du décalage de fréquence entre la machine surveillée par ntpd et la source de référence ; c'est exprimé en PPM, voir les détails ici : http://www.ntp.org/ntpfaq/NTP-s-sw-clocks-quality.htm
Et si je ne me trompe pas, 500 est la valeur maximale, qui fait que ntpd va refuser de superviser l'horloge de la machine.
Avec les liens cités plus haut, on pourrait être tenté de "bidouiller" (voir par exemple http://0x657573.wordpress.com/2010/12/09/setting-up-an-ntp-gateway/ qui est assez gratiné :-)
- soit sur la clocksource du noyau invité - soit sur le paramétrage fin de l'outil de virtualisation (VirtualBox dans ton cas) - soit sur la config ntpd ("tinker panic 0", élimination de "fudge 127.127.1.0 stratum 10" mais en debian ça n'est pas par défaut, "tos maxdist" --- là ça devient très pifométrique) -> tout ça pouvant être combiné
-> idem, les items de cette liste peuvent être combinés.
J'ajoute une 4e bidouille qui est parfois mentionnée : effacer ntp.drift (qui sera recréé au démarrage suivant de ntpd) ; comme l'horloge de l'invité est instable, la valeur est parfois relativement faible et n'empêche plus ntpd de démarrer, mais ça ne garantit rien sur les démarrages suivants.
Les valeurs sont plutôt mauvais signe (même si je n'ai pas cherché les détails pour les interpréter) : https://lists.ntp.org/pipermail/questions/2011-March/028759.html
Ce sont les 8 valeurs les plus récentes du décalage (en millisecondes) entre l'horloge locale et l'horloge de référence. Avec un tel décalage (croissant, en plus), de l'ordre de plusieurs secondes, ntpd ne peut rien faire pour redresser la barre ; il est prévu pour réaliser des ajustements très faibles, afin de lisser l'horloge locale le plus possible...
Les valeurs sont plutôt mauvais signe (même si je n'ai pas cherché les
détails pour les interpréter) :
https://lists.ntp.org/pipermail/questions/2011-March/028759.html
Ce sont les 8 valeurs les plus récentes du décalage (en millisecondes)
entre l'horloge locale et l'horloge de référence. Avec un tel décalage
(croissant, en plus), de l'ordre de plusieurs secondes, ntpd ne peut
rien faire pour redresser la barre ; il est prévu pour réaliser des
ajustements très faibles, afin de lisser l'horloge locale le plus
possible...
Les valeurs sont plutôt mauvais signe (même si je n'ai pas cherché les détails pour les interpréter) : https://lists.ntp.org/pipermail/questions/2011-March/028759.html
Ce sont les 8 valeurs les plus récentes du décalage (en millisecondes) entre l'horloge locale et l'horloge de référence. Avec un tel décalage (croissant, en plus), de l'ordre de plusieurs secondes, ntpd ne peut rien faire pour redresser la barre ; il est prévu pour réaliser des ajustements très faibles, afin de lisser l'horloge locale le plus possible...
-- DW
Erwan David
Damien Wyart écrivait :
* Lucas Levrel in fr.comp.os.linux.configuration:
delay trop grand ? As-tu essayé différents serveurs ? (Dans ma conf j'ai fr.pool.ntp.org, et ntpq donne comme refid ntp-p1.obspm.fr, avec un « delay » 2.404).
Bizarre, normalement fr.pool.ntp.org est un pool de stratum 2, donc ntp-p1.obspm.fr, qui est de stratum 1, ne devrait pas apparaître. Et fr.pool.ntp.org correspond à 4 IP en round robin, mais aucune ne pointe vers obspm. N'as-tu pas un ntp-p1.obspm.fr en dur qui traîne dans ta config ?
Non *.pool.ntp.org n'est *pas* un pool de strate 2.
cf http://www.pool.ntp.org/fr/join.html
« Notez qu'il n'est pas requis que votre serveur soit de strate 1 ou 2 : comme le projet se concentre plus sur la distribution de la charge, il n'y a aucune raison qu'un strate 3 ou même un strate 4 ne puisse pas joindre le projet. »
En plus lucas indique que ntp-p1.obspm.fr est en "refid" il est dnc sur un serveur lui même synchronisé sur ntp-p1.obspm.fr, dont je ne suis pas sûr qu'il soit de strate 1
-- Les simplifications c'est trop compliqué
Damien Wyart <damien.wyart@free.fr> écrivait :
* Lucas Levrel <lucas.levrel@u-pec.fr>
in fr.comp.os.linux.configuration:
delay trop grand ? As-tu essayé différents serveurs ? (Dans ma conf
j'ai fr.pool.ntp.org, et ntpq donne comme refid ntp-p1.obspm.fr, avec
un « delay » 2.404).
Bizarre, normalement fr.pool.ntp.org est un pool de stratum 2, donc
ntp-p1.obspm.fr, qui est de stratum 1, ne devrait pas apparaître. Et
fr.pool.ntp.org correspond à 4 IP en round robin, mais aucune ne pointe
vers obspm. N'as-tu pas un ntp-p1.obspm.fr en dur qui traîne dans ta
config ?
Non *.pool.ntp.org n'est *pas* un pool de strate 2.
cf http://www.pool.ntp.org/fr/join.html
« Notez qu'il n'est pas requis que votre serveur soit de strate 1 ou 2 :
comme le projet se concentre plus sur la distribution de la charge, il
n'y a aucune raison qu'un strate 3 ou même un strate 4 ne puisse pas
joindre le projet. »
En plus lucas indique que ntp-p1.obspm.fr est en "refid" il est dnc sur
un serveur lui même synchronisé sur ntp-p1.obspm.fr, dont je ne suis pas
sûr qu'il soit de strate 1
delay trop grand ? As-tu essayé différents serveurs ? (Dans ma conf j'ai fr.pool.ntp.org, et ntpq donne comme refid ntp-p1.obspm.fr, avec un « delay » 2.404).
Bizarre, normalement fr.pool.ntp.org est un pool de stratum 2, donc ntp-p1.obspm.fr, qui est de stratum 1, ne devrait pas apparaître. Et fr.pool.ntp.org correspond à 4 IP en round robin, mais aucune ne pointe vers obspm. N'as-tu pas un ntp-p1.obspm.fr en dur qui traîne dans ta config ?
Non *.pool.ntp.org n'est *pas* un pool de strate 2.
cf http://www.pool.ntp.org/fr/join.html
« Notez qu'il n'est pas requis que votre serveur soit de strate 1 ou 2 : comme le projet se concentre plus sur la distribution de la charge, il n'y a aucune raison qu'un strate 3 ou même un strate 4 ne puisse pas joindre le projet. »
En plus lucas indique que ntp-p1.obspm.fr est en "refid" il est dnc sur un serveur lui même synchronisé sur ntp-p1.obspm.fr, dont je ne suis pas sûr qu'il soit de strate 1
-- Les simplifications c'est trop compliqué
Damien Wyart
* Erwan David in fr.comp.os.linux.configuration:
Non *.pool.ntp.org n'est *pas* un pool de strate 2.
cf http://www.pool.ntp.org/fr/join.html
Ok, je n'avais pas vérifié.
En plus lucas indique que ntp-p1.obspm.fr est en "refid" il est dnc sur un serveur lui même synchronisé sur ntp-p1.obspm.fr, dont je ne suis pas sûr qu'il soit de strate 1
En effet.
-- DW
* Erwan David <erwan@rail.eu.org> in fr.comp.os.linux.configuration:
Non *.pool.ntp.org n'est *pas* un pool de strate 2.
cf http://www.pool.ntp.org/fr/join.html
Ok, je n'avais pas vérifié.
En plus lucas indique que ntp-p1.obspm.fr est en "refid" il est dnc
sur un serveur lui même synchronisé sur ntp-p1.obspm.fr, dont je ne
suis pas sûr qu'il soit de strate 1
Non *.pool.ntp.org n'est *pas* un pool de strate 2.
cf http://www.pool.ntp.org/fr/join.html
Ok, je n'avais pas vérifié.
En plus lucas indique que ntp-p1.obspm.fr est en "refid" il est dnc sur un serveur lui même synchronisé sur ntp-p1.obspm.fr, dont je ne suis pas sûr qu'il soit de strate 1
En effet.
-- DW
Damien Wyart
> Avec les liens cités plus haut, on pourrait être tenté de > "bidouiller" (voir par exemple > http://0x657573.wordpress.com/2010/12/09/setting-up-an-ntp-gateway/ > qui est assez gratiné :-)
> - soit sur la clocksource du noyau invité > - soit sur le paramétrage fin de l'outil de virtualisation (VirtualBox > dans ton cas) > - soit sur la config ntpd ("tinker panic 0", élimination de "fudge > 127.127.1.0 stratum 10" mais en debian ça n'est pas par défaut, "tos > maxdist" --- là ça devient très pifométrique) -> tout ça pouvant être combiné
> -> idem, les items de cette liste peuvent être combinés.
J'ajoute une 4e bidouille qui est parfois mentionnée : effacer ntp.drift (qui sera recréé au démarrage suivant de ntpd) ; comme l'horloge de l'invité est instable, la valeur est parfois relativement faible et n'empêche plus ntpd de démarrer, mais ça ne garantit rien sur les démarrages suivants.
Une dernière bidouille pour la route, les outils tickadj et adjtimex. Mais là aussi, c'est de l'ordre du pansement sur une jambe de bois...
-- DW
> Avec les liens cités plus haut, on pourrait être tenté de
> "bidouiller" (voir par exemple
> http://0x657573.wordpress.com/2010/12/09/setting-up-an-ntp-gateway/
> qui est assez gratiné :-)
> - soit sur la clocksource du noyau invité
> - soit sur le paramétrage fin de l'outil de virtualisation (VirtualBox
> dans ton cas)
> - soit sur la config ntpd ("tinker panic 0", élimination de "fudge
> 127.127.1.0 stratum 10" mais en debian ça n'est pas par défaut, "tos
> maxdist" --- là ça devient très pifométrique) -> tout ça pouvant être combiné
> -> idem, les items de cette liste peuvent être combinés.
J'ajoute une 4e bidouille qui est parfois mentionnée : effacer
ntp.drift (qui sera recréé au démarrage suivant de ntpd) ; comme
l'horloge de l'invité est instable, la valeur est parfois relativement
faible et n'empêche plus ntpd de démarrer, mais ça ne garantit rien
sur les démarrages suivants.
Une dernière bidouille pour la route, les outils tickadj et adjtimex.
Mais là aussi, c'est de l'ordre du pansement sur une jambe de bois...
> Avec les liens cités plus haut, on pourrait être tenté de > "bidouiller" (voir par exemple > http://0x657573.wordpress.com/2010/12/09/setting-up-an-ntp-gateway/ > qui est assez gratiné :-)
> - soit sur la clocksource du noyau invité > - soit sur le paramétrage fin de l'outil de virtualisation (VirtualBox > dans ton cas) > - soit sur la config ntpd ("tinker panic 0", élimination de "fudge > 127.127.1.0 stratum 10" mais en debian ça n'est pas par défaut, "tos > maxdist" --- là ça devient très pifométrique) -> tout ça pouvant être combiné
> -> idem, les items de cette liste peuvent être combinés.
J'ajoute une 4e bidouille qui est parfois mentionnée : effacer ntp.drift (qui sera recréé au démarrage suivant de ntpd) ; comme l'horloge de l'invité est instable, la valeur est parfois relativement faible et n'empêche plus ntpd de démarrer, mais ça ne garantit rien sur les démarrages suivants.
Une dernière bidouille pour la route, les outils tickadj et adjtimex. Mais là aussi, c'est de l'ordre du pansement sur une jambe de bois...
