horloge : une solution
Salut,
Laurent Picouleau (lcrpic@a2points.com) m'a envoyé, pour résoudre mon
problème d'horloge folle (je rappelle que j'ai remarqué, sur trois
machines avec slink stable, un décalage de plusieurs minutes par jour
des horloges), le fichier suivant. Avec son autorisation, je le publie
ici pour toutes les personnes qui m'ont indiqué avoir un problème
similaire. Il s'agit d'un document de premier jet, donc des
approximations ou des erreurs sont possibles. Laurent Picouleau a
l'intention de l'améliorer et de le rediffuser ensuite.
===============================================================================
Comment régler avec précision l'horloge d'un système linux sans
utiliser xntp.
Ceci suppose que la machine tourne en permanence... Ceci suppose aussi
que l'on ai une heure de référence fiable, par exemple l'horloge
parlante, à chaque fois que l'on utilise hwclock --set ou adjtimex -w
1°) jour
- via le BIOS mettre la machine à l'heure UTC "en gros"
- installer hwclock et adjtimex
- lancer la commande :
hwclock --set --date="8/20/99 hh:mm:00" --utc --debug
ceci a pour effet de créer un fichier /etc/adjtime dont la valeur
de dérive (la première de la première ligne) est inexploitable
2°) jour
- lancer la commande :
hwclock --set --date="8/21/99 hh:mm:00" --utc --debug
maintenant la dérive indiquée par /etc/adjtime est du bon ordre de
grandeur
- *Si* la dérive indiquée dans /etc/adjtime est, en valeur absolue,
supérieure à 8 secondes alors
- lancer :
adjtimex -u -c
- relever la valeur suggérée pour "tick"
- lancer :
adjtimex -u -t=valeur_suggérée
- lancer la commande :
adjtimex -u -l=/var/log/clock.log
7°) jour
- lancer :
adjtimex -u -l=/var/log/clock.log
hwclock --set --date "8/26/99 hh:mm:00" --utc --debug
adjtimex -u -l=/var/log/clock.log
la dérive indiquée dans /etc/adjtime est maintenant précise au
dixième de seconde près.
- maintenant que l'on connait avec une bonne précision le
comportement de l'horloge CMOS, on va pouvoir s'occuper de
l'horloge système
- lancer :
adjtimex -u -w -l=/var/log/clock.log
adjtimex -u -c=22 -i=100
- faire la moyenne des 20 valeurs suggérées pour freq. Ne pas tenir
compte des quatre derniers chiffres des nombres indiqués : ils ont
une influence inférieure au centième de seconde de variation par
jour, vous pouvez donc arrondir sans vergogne
- lancer :
adjtimex -u -f=moyenne_calculée
adjtimex -u -l=/var/log/clock.log
- Voilà, votre horloge système est maintenant calée sur votre
référence et ne se décalera que d'environ un dixième de seconde par
jour.
Remarques :
- Il est plus simple et plus précis d'avoir recours à xntp lorsque
c'est possible (connection correcte à l'internet et accès à un serveur
ntp)
- A propos de la précision indiquée : j'estime qu'entre le moment où
l'on s'attend (anticipation) à entendre le "4° top" et celui où l'on
enfonce effectivement la touche entrée il peut s'écouler de -1/2 à
+1/2 secondes d'où 5 dixièmes d'erreur divisés par les 5 jours
d'attente entre le 2° et le 7° jour.Si vous estimez que vous avez des
nerfs d'acier et des réflexes hyper aiguisés et que vous n'introduirez
pas plus d'un dixième de seconde d'erreur vous pouvez faire les
réglages proposés le 7° jour dès le 3° jour. Si au contraire, cette
demi-seconde d'erreur vous semble grossièrement optimiste et que deux
secondes vous semblent une valeur plus réaliste, il vous faudra
attendre le 22° jour pour effectuer les manips proposées le 7°
- L'option -h de adjtimex est hautement préférable à -w mais suppose
d'être connecté et d'avoir accès à un serveur NTP.
- A priori, en patientant deux mois, on peut reproduire les manips du
septième jour et escompter une précision de un centième de seconde par
jour. Au delà la précision obtenue par ce genre de procédé serait
illusoire, si vos besoins en précision sont supérieurs, il faut avoir
recours à du matériel spécialisé et/ou à un protocole fiable tel que
xntp (pour mémoire l'horloge parlante est fiable à 1/300 seconde près
ce qui résulte en 1/50 pour l'auditeur en prenant en compte le temps
de transmition par le réseau téléphonique. Il s'agit toutefois ici
d'une erreur absolue et non d'une erreur relative par jour...)
===============================================================================
--
Pierre Crescenzo
mailto:Pierre@crescenzo-pierre.nom.fr
http://www.crescenzo-pierre.nom.fr/
Reply to: