Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

[ntp] Écart de l'heure constaté sur 2 machines avec la même configuration

26 réponses
Avatar
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 ?

Pour info, sur la Squeeze j'ai :

~# ntpd --version
ntpd - NTP daemon program - Ver. 4.2.6p2

et sur la Precise j'ai :
~# ntpd --version
ntpd - NTP daemon program - Ver. 4.2.6p3
ntpd 4.2.6p3@1.2290-o Tue Jun 5 20:12:08 UTC 2012 (1)

Merci d'avance pour votre aide.

--
François Lafont

10 réponses

1 2 3
Avatar
Bruno Ducrot
On 2013-05-11, JM Company wrote:
Francois Lafont wrote:

Bonjour à tous,




Salut....... Est ce que les appels au serveur NTP sont envoyés
au même moment sur les deux machines ? Parce que si c'est le cas, le
serveur ne répondra pas à l'une des deux ! En fait il ne répondra pas à
celle qui arrive juste en deuxième. Et cela parce que pour lui il s'agit
de la même machine (même adresse IP) !!!

Il faut alors décaler les appels dans le temps sur tes deux
machines!



Cela aurait pu être effectivement un problème, sauf qu'en fait
le seul problème avec NTP lorsque l'on utilise un NAT se pose
pour l'authentification, sjmsb, ce qui n'est pas le cas ici.

A plus,

--
Bruno Ducrot

A quoi ca sert que Ducrot hisse des carcasses ?
Avatar
JM Company
Bruno Ducrot wrote:

On 2013-05-11, JM Company wrote:
Francois Lafont wrote:

Bonjour à tous,




Salut....... Est ce que les appels au serveur NTP sont envoyés
au même moment sur les deux machines ? Parce que si c'est le cas, le
serveur ne répondra pas à l'une des deux ! En fait il ne répondra pas à
celle qui arrive juste en deuxième. Et cela parce que pour lui il s'agit
de la même machine (même adresse IP) !!!

Il faut alors décaler les appels dans le temps sur tes deux
machines!



Cela aurait pu être effectivement un problème, sauf qu'en fait
le seul problème avec NTP lorsque l'on utilise un NAT se pose
pour l'authentification, sjmsb, ce qui n'est pas le cas ici.

A plus,





Pas besoin d'authentification ! Le serveur ne répond pas pour des
requettes quasi simultanées d'une même IP....... J'ai eu ce problème,
il y a quelque années, avec 4 serveurs derrière un NAT !


JM
Avatar
Nicolas George
JM Company , dans le message <518e1a35$0$2103$, a
écrit :
Pas besoin d'authentification ! Le serveur ne répond pas pour des
requettes quasi simultanées d'une même IP....... J'ai eu ce problème,
il y a quelque années, avec 4 serveurs derrière un NAT !



Sauf erreur de ma part, si le serveur ne répond pas, le client réessaiera
plus tôt que si le serveur répond, ce qui fait qu'à part la première fois,
les requêtes seront facilement déphasées.

Évidemment, le nombre de requêtes va être multiplié par le nombre de
clients, ce qui peut déplaire aux serveurs. Il vaudrait mieux installer un
serveur local.
Avatar
JM Company
Nicolas George wrote:

JM Company , dans le message <518e1a35$0$2103$, a
écrit :
Pas besoin d'authentification ! Le serveur ne répond pas pour des
requettes quasi simultanées d'une même IP....... J'ai eu ce problème,
il y a quelque années, avec 4 serveurs derrière un NAT !



Sauf erreur de ma part, si le serveur ne répond pas, le client réessaiera
plus tôt que si le serveur répond, ce qui fait qu'à part la première fois,
les requêtes seront facilement déphasées.




Sauf si l'on n'utilise pas de daemon local et que les requettes
sont faites via le cron et à heure fixe !!

JM
Avatar
Bruno Ducrot
On 2013-05-11, JM Company wrote:
Nicolas George wrote:

JM Company , dans le message <518e1a35$0$2103$, a
écrit :
Pas besoin d'authentification ! Le serveur ne répond pas pour des
requettes quasi simultanées d'une même IP....... J'ai eu ce problème,
il y a quelque années, avec 4 serveurs derrière un NAT !



Sauf erreur de ma part, si le serveur ne répond pas, le client réessaiera
plus tôt que si le serveur répond, ce qui fait qu'à part la première fois,
les requêtes seront facilement déphasées.




Sauf si l'on n'utilise pas de daemon local et que les requettes
sont faites via le cron et à heure fixe !!



Vous avez raison pour ce cas en particulier. Par contre, l'OP a bien
précisé qu'il utilisait justement ntpd afin de syncroniser ses machines
virtuelles.

A plus,

--
Bruno Ducrot

A quoi ca sert que Ducrot hisse des carcasses ?
Avatar
Francois Lafont
Bonjour,

Merci à tous pour vos réponses.

En fait, il s'est passé quelque chose de bien frustrant aujourd'hui : je démarre les VM sans avoir touché à quoi que ce soit depuis hier soir et bien sûr, comme par hasard, les deux VM se synchronisent parfaitement sur le même serveur.

Très honnêtement, je ne comprends pas ce qu'il s'est passé. Par rapport à l'hypothèse des requêtes simultanées, je ne pense pas que ça soit ça car 1) avec les tcpdump d'hier sur les 2 VM je me rappelle bien les requêtes n'étaient pas simultanées et 2) sur la Squeeze récalcitrante j'avais aussi tenté hier soir de prendre comme serveurs distants les {0,1,2,3,4}.fr.pool.ntp.org sans succès non plus (j'ai remis ensuite le même serveur distant dans la conf des deux VM avant de les éteindre).

Merci à Damien pour ses 2 liens qui m'ont l'air très intéressants :
http://rags.wordpress.com/2011/10/17/how-to-debug-ntp-issues/
http://www.eecis.udel.edu/~mills/ntp/html/debug.html

Bon, ça va être dur d'élucider le problème maintenant. Si jamais ça se reproduit, je reviendrai à la charge sur ce fil armé des commandes citées dans le premier lien de Damien. Évidemment si vous avez des idées de manips dans l'immédiat, je suis preneur mais maintenant que le problème a disparu, je crains qu'il n'y ait pas grand chose à faire pour le moment.

--
François Lafont
Avatar
fm
Francois Lafont wrote:
Bonjour,

Merci à tous pour vos réponses.

En fait, il s'est passé quelque chose de bien frustrant aujourd'hui :
je démarre les VM sans avoir touché à quoi que ce soit depuis hier
soir et bien sûr, comme par hasard, les deux VM se synchronisent
parfaitement sur le même serveur.

Très honnêtement, je ne comprends pas ce qu'il s'est passé. Par
rapport à l'hypothèse des requêtes simultanées, je ne pense pas
que ça soit ça car 1) avec les tcpdump d'hier sur les 2 VM je me
rappelle bien les requêtes n'étaient pas simultanées et 2) sur la
Squeeze récalcitrante j'avais aussi tenté hier soir de prendre comme
serveurs distants les {0,1,2,3,4}.fr.pool.ntp.org sans succès non
plus (j'ai remis ensuite le même serveur distant dans la conf des
deux VM avant de les éteindre).

Merci à Damien pour ses 2 liens qui m'ont l'air très intéressants :
http://rags.wordpress.com/2011/10/17/how-to-debug-ntp-issues/
http://www.eecis.udel.edu/~mills/ntp/html/debug.html

Bon, ça va être dur d'élucider le problème maintenant. Si jamais
ça se reproduit, je reviendrai à la charge sur ce fil armé des
commandes citées dans le premier lien de Damien. Évidemment si vous
avez des idées de manips dans l'immédiat, je suis preneur mais
maintenant que le problème a disparu, je crains qu'il n'y ait pas
grand chose à faire pour le moment.



Bonjour,

C'est un peu en retard et c'est juste des pistes :

ntp évalue, ajuste et maintient constamment l'écart de
fréquence de l'horloge système dans un fichier (par défaut
/etc/ntp.drift). Une fois ntpd chaud (ce qui peut prendre du
temps, en heures), ntp.drift est aussi stable que possible
et est utilisé pour piloter la fréquence de l'horloge système.

Si la fréquence de cette horloge système est trop dans les choux
(à cause par exemple d'une horloge matérielle pourrie),
la pente peut être trop raide pour les braquets par défaut
du démon ntp, qui va pédaler un moment en reculant avant de jeter
le vélo dans le ravin (c'est très imagé...)

Qu'est-ce qu'il y a dans /etc/ntp.drift maintenant par exemple ?

VM c'est pour "virtual machine" ? Si oui, ce n'est potentiellement
pas tout à fait innocent non plus, à vérifier.

--
François Meyer
Avatar
Francois Lafont
Bonsoir,

Le 23/05/2013 12:25, a écrit :

C'est un peu en retard



Pas de souci. Chacun son rythme sur les forums. ;-)
En plus j'ai ma Squeeze qui à nouveau ne veut plus se synchroniser.

et c'est juste des pistes :

ntp évalue, ajuste et maintient constamment l'écart de
fréquence de l'horloge système dans un fichier (par défaut
/etc/ntp.drift). Une fois ntpd chaud (ce qui peut prendre du
temps, en heures), ntp.drift est aussi stable que possible
et est utilisé pour piloter la fréquence de l'horloge systéme.

Si la fréquence de cette horloge système est trop dans les choux
(à cause par exemple d'une horloge matérielle pourrie),
la pente peut être trop raide pour les braquets par défaut
du démon ntp, qui va pédaler un moment en reculant avant de jeter
le vélo dans le ravin (c'est très imagé...)

Qu'est-ce qu'il y a dans /etc/ntp.drift maintenant par exemple ?



Sur ma Squeeze, le fichier n'est pas au même endroit et j'ai ça :

~# cat /var/lib/ntp/ntp.drift
500.000

Et il signifie quoi ce 500.000 exactement ?

VM c'est pour "virtual machine" ?



Oui, des VM Virtualbox toutes bêtes.

Si oui, ce n'est potentiellement
pas tout à fait innocent non plus, à vérifier.



Ah... peut-être bien. Là, avec Virtualbox, j'ai de la full virtualisation il me semble alors je me dis que le souci ne vient pas de là mais je me trompe peut-être.

En tout cas, ma Squeeze repart dans les choux :

~# ntpq -pn
remote refid st t when poll reach delay offset jitter
============================================================================= 212.27.60.17 91.121.154.174 3 u 48 64 377 19.944 10333.7 5695.79

Fort du lien que m'a passé Damien (http://rags.wordpress.com/2011/10/17/how-to-debug-ntp-issues/), j'essaye d'en savoir plus :

---------------------------------------------------------------
~# ntpq
ntpq> as

ind assid status conf reach auth condition last_event cnt
========================================================== 1 24386 9024 yes yes none reject reachable 2

ntpq> rv 24386
associd$386 status24 conf, reach, sel_reject, 2 events, reachable,
srcadr=webcgi1-g20.free.fr, srcport3, dstadr2.168.0.20,
dstport3, leap, stratum=3, precision=-20, rootdelay=5.310,
rootdispR.856, refid‘.121.154.174,
reftimeÕ52470c.d996f9af Thu, May 30 2013 23:45:48.849,
recÕ524af3.d72c53cf Fri, May 31 2013 0:02:27.840, reach77,
unreach=0, hmode=3, pmode=4, hpoll=6, ppoll=6, headway=0,
peer_dist, keyid=0, offset619.969, delay#.917,
dispersion=0.961, jitterW00.795, xleave=2.215,
filtdelay= 23.92 19.94 20.46 19.13 20.00 20.14 22.95 20.87,
filtoffset= 11619.9 10333.7 9086.15 7838.51 6551.21 5244.38 3937.53 2689.17,
filtdisp= 0.02 1.01 1.97 2.93 3.92 4.92 5.93 6.89
ntpq>
---------------------------------------------------------------

Et là j'ai le même souci que celui décrit dans le lien : « " peer_dist". This flash code corresponds to "distance threshold exceeded". »

Ok, j'ai dépassé un seuil d'une certaine distance, mais une distance entre quoi et quoi ?

Au départ, je pensais que cette distance était l'écart entre mon heure et celle du serveur ntp sur lequel je souhaite me synchroniser mais je ne pense pas finalement que ça soit ça car avant de relancer ntpd (et qu'il ne parte en cacahuète), j'ai bien fait :

---------------------------------------------------------------
~# invoke-rc.d ntp stop
Stopping NTP server: ntpd.

~# ntpd -gq
ntpd: time set +18.157637s

~# ntpd -gq # j'en remets une couche
ntpd: time set +0.199055s

~# invoke-rc.d ntp start
Starting NTP server: ntpd.
---------------------------------------------------------------

Donc j'avais eu la gentillesse de relancer ntpd alors que le temps était déjà synchronisé.

Bref, je ne comprends pas trop la raison qui fait que la synchronisation ne se fait pas et du coup je ne sais pas comment y remédier. Peut-être que certains parmi vous sauront interpréter toutes les valeurs ci-dessus (ntp m'a l'air d'être un protocole à pas piquer des hannetons ;-)).

Merci d'avance pour vos lumières.


--
François Lafont
Avatar
Lucas Levrel
Le 31 mai 2013, Francois Lafont a écrit :

Et là j'ai le même souci que celui décrit dans le lien : « "
peer_dist". This flash code corresponds to "distance threshold
exceeded". »

Ok, j'ai dépassé un seuil d'une certaine distance, mais une distance
entre quoi et quoi ?



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).

--
LL
Avatar
Damien Wyart
Bonjour,

Je vais essayer de répondre, et ça risque d'être un peu long :)

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.

Je vais donner d'autres détails, mais je pense que le plus simple est de
renoncer à NTP dans les VMs (mais le conserver sur la machine physique
pour que l'horloge système soit fiable) et d'utiliser les "Vbox Guest
Additions" pour effectuer le synchronisation des VMs sur la machine
physique. Normalement tu as juste à installer ça et cela doit suffire
(on peut tuner comme indiqué plus loin mais pas sûr du tout que ça soit
nécessaire dans ton cas).

* Francois Lafont
in fr.comp.os.linux.configuration:
Sur ma Squeeze, le fichier n'est pas au même endroit et j'ai ça :

~# 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

> VM c'est pour "virtual machine" ?

Oui, des VM Virtualbox toutes bêtes.

Ah... peut-être bien. Là, avec Virtualbox, j'ai de la full
virtualisation il me semble alors je me dis que le souci ne vient pas
de là mais je me trompe peut-être.



Il y a de très fortes chances que le problème vienne de là ; une
recherche Google donne énormément de choses (à la fois en nombre de
résultats, et certains résultats sont particulièrement verbeux) :

http://www.vmware.com/files/pdf/techpaper/Timekeeping-In-VirtualMachines.pdf
https://www.virtualbox.org/ticket/3135 (particulièrement long !)
https://www.virtualbox.org/ticket/3569 (la conclusion qui est je pense la plus simple)
https://forums.virtualbox.org/viewtopic.php?f=1&t'521 (pareil)
https://lists.ntp.org/pipermail/questions/2011-March/028783.html (encore)
https://lists.ntp.org/pipermail/questions/2011-March/thread.html#28757 (là le thread est vraiment immense et part en troll par moments)
http://log.or.cz/?p€
http://serverfault.com/questions/106501/what-are-the-limits-of-running-ntp-servers-in-virtual-machines
http://support.ntp.org/bin/view/Support/VMWareNTP
http://support.ntp.org/bin/view/Support/KnownOsIssues#Section_9.2.2.
http://www.virtualbox.org/manual/ch09.html#changetimesync (des infos pour tuner la synchro des VMs sur la machine support)
http://stackoverflow.com/questions/117422/how-can-i-resolve-the-drifting-clock-for-my-virtual-machine
http://serverfault.com/questions/56483/how-do-i-stop-the-clock-running-fast-on-a-virtualbox-client-running-ubuntu-8-04
http://askubuntu.com/questions/280421/ubuntu-inside-virtual-machine-ntpd-or-ntpdate-or-to-avoid-clock-drift
http://serverfault.com/questions/365690/best-practices-for-ntp-updating-in-virtualbox-virtual-machines-without-guest-add
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId06427
http://www.vr.org/kb/161/My-server-clock-or-date-and-time-is-wrong-or-drifts.html
http://hydra.geht.net/tino/howto/virtualbox/linux/time/

filtoffset= 11619.9 10333.7 9086.15 7838.51 6551.21 5244.38 3937.53 2689.17,



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

Et là j'ai le même souci que celui décrit dans le lien : « "
peer_dist". This flash code corresponds to "distance threshold
exceeded". »

Ok, j'ai dépassé un seuil d'une certaine distance, mais une distance
entre quoi et quoi ?



C'est assez compliqué :
http://www.eecis.udel.edu/~mills/ntp/html/select.html

mais au vu des liens précédents, je dirais que c'est un "effet de bord"
du comportement de l'horloge de la VM, qui perturbe ntpd et ses
algorithmes, qui sont prévus pour une horloge "physique" (en VM il
y a une couche "d'émulation"). De plus, sous Linux, plusieurs sources de
temps sont utilisables et n'ont pas le même comportement, en physique
comme en émulé (on le voit dans le PDF VMware que j'ai cité plus haut).

Au départ, je pensais que cette distance était l'écart entre mon heure
et celle du serveur ntp sur lequel je souhaite me synchroniser mais je
ne pense pas finalement que ça soit ça car avant de relancer ntpd (et
qu'il ne parte en cacahuète), j'ai bien fait :

---------------------------------------------------------------
~# invoke-rc.d ntp stop
Stopping NTP server: ntpd.

~# ntpd -gq
ntpd: time set +18.157637s

~# ntpd -gq # j'en remets une couche
ntpd: time set +0.199055s

~# invoke-rc.d ntp start
Starting NTP server: ntpd.
---------------------------------------------------------------



Ce qui pose problème n'est pas "l'alignement" de la VM et de la source
NTP mais le fait que la source de temps de la VM n'est pas assez
régulière.

Bref, je ne comprends pas trop la raison qui fait que la
synchronisation ne se fait pas et du coup je ne sais pas comment
y remédier.



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.

Bref, on ne sait plus trop ce que l'on fait, et si ça marche, on ne sait
pas si ça continuera à marcher, et qu'est-ce qui a vraiment fait que ça
marche, et surtout c'est long de tester toutes ces combinaisons qui au
final contournent ou masquent la cause de départ du problème.

Donc en conclusion (comme indiqué en début de ma réponse), je pense que
le plus sage est d'avoir ntpd sur la machine physique, et les outils
Vbox sur les invités qui activeront une synchronisation sur la machine
physique (elle étant synchronisée sur une source fiable), bref on fait
une chaine simple plutôt qu'un enchevêtrement :)

Peut-être que certains parmi vous sauront interpréter toutes les
valeurs ci-dessus (ntp m'a l'air d'être un protocole à pas piquer des
hannetons ;-)).



NTP est en effet très complexe, il existe un ouvrage de 500 pages qui
l'explique en détail :
http://www.amazon.fr/Computer-Network-Time-Synchronization-Protocol/dp/1439814635/

Sans te vexer (je n'aime pas trop reprendre les gens sur ces aspects),
l'expression correcte est "ne pas être piqué des hannetons" :
http://www.cnrtl.fr/definition/hanneton, c'est à dire être remarquable
ou de bonne qualité puisque les hannetons ou autres parasites ne s'y
attaquent pas.)


En espérant avoir aidé...
--
DW
1 2 3