Installation ntp ntpd adjtimex

Vendredi 16 Novembre 2001
La liste des serveurs NTP français se trouve à:
http://www.cru.fr/NTP/serveurs_francais.html
Voir le HOWTO Clock
Pour l'utilisation de ntpd sur réseau non connecté en permanence, il existe aussi chrony (disponible dans la section OPTIONAL/ADMIN de Debian. The chrony web page
Une fois les paquets installés, il n'y a pas de man mais il y a de la bonne doc sous /usr/doc ...
Pour les stations WINDAUBE dans le réseau, il existe des produits pour se synchroniser sur les serveurs NTP. Il y a un site qui traite de la synchronisation en général Time Synchronization Server -- Time Synchronization Software . Il répertorie un tas de logiciels pour différentes plate-formes dont WINDAUBE. On y trouve également des tuyaux intéressants dans une FAQ NTP.

haut antares, SLACKWARE 8.0 (pour s'ajuster sur vega)

# installpkg ntp4.tgz (n1)
Essais:
# ntptrace -dv canon.inria.fr
pour voir l'écart de temps,
# ntpdate canon.inria.fr
pour ajuster l'horloge,
fonctionnent correctement.
antares se synchronisera sur vega quand ce dernier sera au point:
# ntpdate vega.bd.fr

Mise à jour par cron de root chaque heure à h+0mn:
# crontab -e (édite la crontab de root)
ajoute la ligne:
0 * * * * /usr/sbin/ntpdate vega.bd.fr 1> /dev/null 2> /dev/null
# ntptrace -dv vega.bd.fr (fait avant et après l'heure met en évidence qu'on rattrappe 0,6 seconde par heure)


La doc de la version de ntpd distribuée avec SLACKWARE 8.0 dit que ntptrace n'en a plus pour longtemps! Il est conseillé de le remplacer par ntpd avec le paramètre de lancement -q pour qu'il quitte après synchronisation.

Dans le /etc/ntp.conf livré:
Enlevé:
#server 127.127.1.0 # local clock
#fudge 127.127.1.0 stratum 10
#multicastclient # listen on default 224.0.1.1
#broadcastdelay 0.008
Ajouté:
server vega.bd.fr iburst
Essayé:
# /usr/sbin/ntpd -q
Il s'écoule quelques temps avant que ntpd quitte mais cela marche:
ntpd: time reset -1.246658 s
Attente... On perd 1,3 s en 4 heures. Oui mais...
ntpdate lui, se tire si le serveur ne répond pas et il vide ses poubelles avant de partir. Retour arrière!
crontab pour lancer ntpdate à l'heure et à la demi:
0,30 * * * * /usr/sbin/ntpdate vega.bd.fr 1> /dev/null 2> /dev/null


Il y a mieux à faire avec le rapport de la commande ntpdate que de le poubeller: Il y a un paramètre -s pour rediriger les sorties vers le syslog:
# crontab -e
0,30 * * * * /usr/sbin/ntpdate -s vega.bd.fr
En fait, les sorties se font sur /var/log/messages et non pas syslog. Exemple de rapport:
Nov 25 18:00:02 antares ntpdate[413]: adjust time server 192.168.210.5 offset -0.115636 sec


On glisse de -116ms environ par demi-heure. En faisant des ntptrace on voit l'écart diminuer puis remonter en l'espace d'une demi-heure. La correction est étalée sur environ 5mn. En fait la correction est trop forte (c'est signalé dans la doc de ntpdate), elle dépasse le 0 puis on constate à nouveau le glissement dans l'autre sens. Satisfaisant...


Essai de réglage du tick:
Mesure du glissement de l'horloge système. Arrêter la mise à jour par cron, synchroniser l'horloge par ntpdate , attendre un bon moment, re synchroniser par ntpdate, relever le glissement entre les 2 synchronisations (les rapports de ntpdate vont dans /var/log/messages).
# crontab -e
#15,45 * * * * /usr/sbin/ntpdate -s vega.bd.fr
# ntpdate -b -s -p 4 mesior.obspm.fr
...
# ntpdate -b -s -p 4 mesior.obspm.fr
Résultat:
Nov 29 15:28:13 antares ntpdate[369]: step time server 145.238.2.24 offset -0.421442 sec
Nov 29 22:30:41 antares ntpdate[404]: step time server 145.238.2.24 offset -2.332787 sec
Avance de 2.332787 secondes sur 7h 2mn 28s ou 25348 secondes.
Soit 7.951428 secondes sur un jour ou 86400 secondes.
Valeur du tick actuel:
# tickadj
tick = 10000
Il y a 86400000000/10000 ticks par jour, soit 8640000.
Si je mets le tick à 9999 microsecondes au lieu de 10000,
je gratte donc 8640000 microsecondes soit 8.64 secondes.
Cela fait 8.64-7.951428= 0.688572 de trop.
Pour ajouter ou retirer une fraction de tick, on joue sur frequency .
1 tick (8.64 s/jour) équivaut à 6553600 en frequency en + ou en -.
Avec tickadj on ne peut apparemment que modifier tick . En revanche on peut agir sur tick et frequency avec adjtimex . Cette commande est disponible sous Debian mais pas sous Slackware. Qu'à cela ne tienne, je la copie carrément sous /sbin sans rien demander à personne, et ça va...
Calcul de frequency: 6553600*0.688572/8.64= 522295 en +
Réglage:
# adjtimex --tick 9999 --frequency 522295
Ajouté à /etc/rc.d/rc.local
# ntpdate -b -s -p 4 mesior.obspm.fr
...
# ntpdate -b -s -p 4 mesior.obspm.fr
Résultat:
Nov 30 09:01:16 antares ntpdate[268]: step time server 145.238.2.24 offset -0.360822 sec
Nov 30 20:43:34 antares ntpdate[382]: step time server 145.238.2.24 offset 0.029448 sec
Retard de 0.029448 secondes en 11h 42mn 18s soit 42138 secondes.
Ce qui fait par jour de 86400 secondes, 0.060380 secondes.
Traduit en frequency: +45799
522295+45799= 568094
adjtimex --tick 9999 --frequency 568094
Nouvelle mesure sur une journée de fontionnement:
Résultat:
Dec  2 09:22:07 antares ntpdate[272]: step time server 145.238.2.24 offset -0.451624 sec
 2 Dec 23:12:51 ntpdate[348]: adjust time server 138.195.130.71 offset -0.035041 sec
 Avance de 0.035041 secondes en 13h 50mn soit 49800 secondes.
Ce qui fait par jour, 0.06 secondes.
L'erreur est dans l'autre sens! Des ntptrace successifs montrent qu'on est dans la fourchette d'incertitude de ntpdate sur ce type de connexion. Inutile de régler frequency avec une résolution importante. Comme antares sera asservi à vega, on arrondi frequency à 530000 et on n'en parle plus.
Ajouté à /etc/rc.d/rc.local
/sbin/adjtimex --tick 9999 --frequency 530000


Maintenant que vega est un serveur NTP fiable, on l'utilise pour asservir antares avec ntpdate.
La progression de l'horloge système est déjà réglée au mieux par adjtimex.
Synchronisation initiale brute par le script /etc/rc.d/rc.local:
/sbin/adjtimex --tick 9999 --frequency 530000
/usr/sbin/ntpdate -b -s vega.bd.fr
Synchronisation périodique douce par cron (à h+15 et h+45):
15,45 * * * * /usr/sbin/ntpdate -s vega.bd.fr



Et l'horloge matérielle

Après  une mise hors tension de la bécane on se retrouve encore avec l'horloge décalée parce que celle-ci  s'initialise à partir de l'horloge matérielle et que cette dernière n'est pas asservie.
L'horloge système est copiée dans l'horloge matérielle à la fermeture du système d'exploitation mais l'horloge matérielle est livrée à elle-même pendant la période de mise hors tension (maitenue par pile). L'horloge matérielle est contrôlée par la commande hwclock.
Avec SLACKWARE:
A  l'arrêt du système,  dans /etc/rc.d/rc.0 alias rc.6, lancement de la commande
hwclock  --utc --systohc
Au démarrage du système, dans /etc/rc.d/rc.S, lancement de la commande
hwclock --utc --hctosys
Chaque fois que l'horloge matérielle est mise à l'heure un fichier /etc/adjtime est généré contenant entre autre le décalage de l'horloge. Il est possible de prendre en compte ce décalage enregistré en mettant à l'heure l'horloge matérielle par la commande
hwclock --utc --adjtime
D'après le man hwclock, il est conseillé de lancer cette commande à l'initialisation du système avant d'initialiser l'horloge système à partir de l'horloge matérielle (cela n'est pas fait par défaut)...
Test de la commande hwclock avec les paramètres --debug et --test pour avoir le détail de ce que fait la commande et pour ne pas vraiment mettre l'horloge à l'heure (lancement à blanc).
# hwclock --utc --systohc --debug --test
# cat /etc/adjtime
Le décalage n'est pas enregistré dans /etc/adjtime si la précédente mise à jour date de moins d'un jour (le décalage reste à 0). Il faut attendre au moins un jour après la dernière mise hors tension.
# hwclock --systohc --utc --debug --test
hwclock 2.4c/util-linux-2.11f
hwclock: Open of /dev/misc/rtc failed, errno=2: No such file or directory.
Using direct I/O instructions to ISA clock.
Last drift adjustment done at 1007596352 seconds after 1969
Last calibration done at 1007596352 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2001/12/06 23:30:32
Hw clock time : 2001/12/06 23:30:32 = 1007681432 seconds since 1969
Time elapsed since reference time has been 0.194954 seconds.
Delaying further to reach the next full second.
Setting Hardware Clock to 23:30:31 = 1007681431 seconds since 1969
Clock not changed - testing only.
Clock drifted -2 seconds in the past 85080 seconds in spite of a drift factor of 0.000000 seconds/day.
Adjusting drift factor by -2.031030 seconds/day
Not updating adjtime file because of testing mode.
Would have written the following to /etc/adjtime:
-2.031030 1007681430 0.000000
1007681430
UTC
 L'horloge matérielle avance d'environ 2 secondes par 24 heures. On enregistre la valeur pour de bon:
# hwclock --systohc --utc --debug
hwclock 2.4c/util-linux-2.11f
hwclock: Open of /dev/misc/rtc failed, errno=2: No such file or directory.
Using direct I/O instructions to ISA clock.
Last drift adjustment done at 1007596352 seconds after 1969
Last calibration done at 1007596352 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2001/12/06 23:46:47
Hw clock time : 2001/12/06 23:46:47 = 1007682407 seconds since 1969
Time elapsed since reference time has been 0.180845 seconds.
Delaying further to reach the next full second.
Setting Hardware Clock to 23:46:46 = 1007682406 seconds since 1969
Clock drifted -2 seconds in the past 86055 seconds in spite of a drift factor of 0.000000 seconds/day.
Adjusting drift factor by -2.008018 seconds/day
# cat /etc/adjtime
-2.008018 1007682405 0.000000
1007682405
UTC
On ajoute l'ajustement de l'horloge matérielle dans le startup /etc/rc.d/rc.S avant l'initialisation de l'horloge système:
    echo "Ajuste l'horloge CMOS."
    /sbin/hwclock --utc --adjust
    /sbin/hwclock --utc --hctosys
 C'est mieux mais on constate encore des erreurs variables qui peuvent atteindre plusieurs secondes, au démarrage du système après une période de mise hors tension...
Essai en configurant Enhanced Real Time Clock:
Comme l'indique le rapport de la commande hwclock, l'horloge matérielle est lue en faisant une I/O directe. La tentative d'accès au device RTC échoue parce que le noyau ne le supporte pas. On recompile le noyau avec l'option:
Character devices, Enhanced Real Time Clock Support (CONFIG_RTC)
Essai de hwclock pour vérifier:
# hwclock --show --debug
hwclock 2.4c/util-linux-2.11f
Using /dev/rtc interface to clock.
Last drift adjustment done at 1010771761 seconds after 1969
Last calibration done at 1010771761 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2002/01/12 00:32:37
Hw clock time : 2002/01/12 00:32:37 = 1010795557 seconds since 1969
Sat Jan 12 01:32:37 2002  -0.616688 seconds
Cela fonctionne mais hwclock n'a pas l'air plus exact pour autant...



 

haut vega, DEBIAN 2.2 (prévu pour être le serveur ntp local)

dselect, les paquets suivants:
adjtimex
ntp
ntpdate
ntp-doc
Configuration: Voir ntp.conf et /etc/init.d/ntpdate
Sans qu'on fasse quoi que ce soit ntpd est lancé avec un ntp.conf par défaut:
# /etc/ntp.conf, configuration for xntpd
# ntpd will use syslog() if logfile is not defined
#logfile /var/log/ntpd
driftfile /var/lib/ntp/ntp.drift
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
#server
Il n'y a pas de serveur NTP configuré.
Essai:
# ntpdate canon.inria.fr
Ne fonctionne pas parce que le port NTP est occupé...
D'après la doc, c'est normal: ntpdate ne touche à rien si ntpd est déjà là...
il faut arrêter ntpd avant:
# /etc/init.d/ntp stop
Comme on n'est pas connecté en permanence à Internet, on va simplifier en synchronisant sur l'horloge matérielle. La recette est indiquée dans la doc /ntp/README.Debian:
Ajout à /etc/ntp.conf:
server 127.127.1.1
fudge 127.127.1.1 stratum 10
canon.inria.fr est un serveur primaire de strate 1 prévu pour synchroniser les serveurs publics de strate 2.
Il est correct d'utiliser des serveurs de strate 2 proches. Exemples:
ntp.obspm.fr
 lptfop@obspm.fr
ntp0.oleane.net
ntp1.oleane.net		 ntp-adm@oleane.net
ntp.via.ecp.fr
 ntp-adm@via.ecp.fr
ntp.internet-fr.net
ntp.polytechnique.fr
 ntpmaster@polytechnique.fr
# ntptrace -dv ntp.obspm.fr (pour voir l'écart)
# ntpdate ntp.obspm.fr (pour ajuster)
# /etc/init.d/ntp start (pour relancer ntpd)

# ntptrace -dv ntp.obspm.fr (montre qu'on prend de l'avance: ~2,5 secondes en 12 heures)

On se lance: ajout de 3 serveurs distants dans ntp.conf
server ntp.obspm.fr
server ntp.u-psud.fr
server ntp.via.ecp.fr
Vérification du fonctionnement en suivant les conseils donnés par la page de doc html debug.html
Quand on coupe Internet, la période de polling des serveurs passe de 64 secondes à 1024 secondes! Ajouté le paramètre maxpoll 7 (puissance de 2) pour de pas poller au-delà de 128s
Le processus d'asservissement reste très lent. Si on charge le modem, les serveurs passent en reject probablement à cause du jitter qui monte énormément dans ce cas.
Le fichier /var/lib/ntp/ntp.drift varie au bout d'un long moment connecté à Internet.
Je laisse le PC allumé pendant + de 24h pour voir si l'horloge interne se stabilise (internet non connecté ;-)

Il y a des options de ntpd prévue pour améliorer le fonctionnement dans le cas d'une connexion Internet
non permanente. Voir burst et iburst dans les options de la directive server. Voir aussi le paramètre de
lancement -x. Ces paramètres devraient accélérer le processus...
iburst n'est pas reconnu sous Debian. En fait la version ntpd Debian 2.2 (4.0.99g-2) est antérieure à la version livrée avec SLACKWARE 8.0 (4.0.99k23)...
Essai avec dans ntp.conf
server ntp.obspm.fr burst maxpoll 7
server ntp.u-psud.fr burst maxpoll 7
server ntp.via.ecp.fr burst maxpoll 7
Pour mettre le paramètre de lancement -x dans
/etc/init.d/ntp
attention!
start, stop et restart sont effectués par start-stop-daemon
il faut mettre -- -x
sauvegardé le fichier origine dans ntp.orig

-x n'accélère rien au contaire, il oblige à ajuster l'horloge lentement. Quand on enlève l'option, l'horloge se remet à jour d'un bond si le décallage est suffisamment important. En principe 128ms mais il semble que ce soit plus...

Dès qu'on est déconnecté d'Internet. L'horloge se remet à dériver de plusieurs secondes par jour. Essai sans mettre l'horloge matérielle comme serveur...
#server 127.127.1.1
#fudge 127.127.1.1 stratum 10
Positif! On ne prend plus qu'un peu plus de 300ms en 10h.


Mesures suivantes (connexions à Internet suivantes):
245ms en 14h. 5mn de connexion sont nécessaires pour déclencher la synchronisation.
Pas d'écart notable 8h plus tard...
Il semble que tout dépende de l'état dans lequel a été positionné frequency visualisé par
# ntpq -c rv
qui est égal à /var/lib/ntp/ntp.drift
Il semble que cette valeur soit mise à jour environ 1 heure après que ntpd ait réussi à se synchroniser sur un serveur ntp (connexion à Internet). Suivant la qualité de la liaison avec les serveur ntp (accès Internet chargé ou non) cette valeur est soit correcte, soit dans les choux! Dans le meilleur des cas on glisse de presque rien pendant l'absence de connexion, dans le pire des cas on glisse de plusieurs secondes!


Essai avec plus de serveurs et avec une fréquence de polling plus élevée. Modification de la liste de serveurs dans ntp.conf :
server ntp.obspm.fr burst minpoll 5 maxpoll 7
server ntp0.oleane.net burst minpoll 5 maxpoll 7
server ntp1.oleane.net burst minpoll 5 maxpoll 7
server ntp.via.ecp.fr burst minpoll 5 maxpoll 7
server ntp.internet-fr.net burst minpoll 5 maxpoll 7
server ntp.polytechnique.fr burst minpoll 5 maxpoll 7
# /etc/init.d/ntp restart
ntpd nage la dedans comme un poisson dans l'eau. Il change le statut des serveurs au gré des variations de performances des échanges. Le serveur élu change régulièrement. Il semble choisir celui qui a le moins de jitter. La synchronisation semble plus rapide. Quand on charge la liaison Internet, le jitter augmente considérablement et ntpd lache tous les serveurs en statut reject.
Comme le veut l'étiquette, j'envoie un mel aux administrateurs des serveurs pour dire que j'utilise leur service.


Essai de réglage du tick:
Mesure du glissement de l'horloge système. Arrêter ntpd , synchroniser l'horloge par ntpdate, attendre un bon moment, re synchroniser par ntpdate, relever le glissement entre les 2 synchronisations (les rapports de ntpdate vont dans /var/log/syslog).
# /etc/init.d/ntp stop
# ntpdate -b -s -p 4 mesior.obspm.fr
...
# ntpdate -b -s -p 4 mesior.obspm.fr
Résultat:
Nov 29 15:10:59 vega ntpdate[986]: step time server 145.238.2.24 offset -0.118297 sec
Nov 29 22:30:27 vega ntpdate[6442]: step time server 145.238.2.24 offset -0.432141 sec
-0.432141 seconde en 26368 secondes
Attention! tick était bien à 10000 par défaut mais frequency n'était pas à 0. Il était à 5989884 (ce qui représenterait une correction de presque +8 secondes).
Comme l'indique:
# adjtimex --print
ou
# ntptime
On recommence après:
# adjtimex -f 0
Le man de adjtimex explique pas mal.
Nov 30 01:32:48 vega ntpdate[7638]: step time server 145.238.2.24 offset 0.453385 sec
Nov 30 09:01:13 vega ntpdate[8969]: step time server 145.238.2.24 offset 2.170551 sec
 Retarde de 2.170551 secondes en 7h 28mn 25s ou 26905 secondes.
En 1 jour, soit 86400 secondes, le retard serait de 6.97 secondes.
Valeur du tick actuel en microsecondes:
# tickadj
tick = 10000
+ ou - 1 µs sur tick vaut + ou - 8.64 secondes par jour (~100 ppm).
Pour l'ajustement fin on agit sur un autre paramètre de l'horloge du noyau: frequency.
+ ou - 6553600 sur frequency équivaut à + ou - 1 µs sur tick soit ~100 ppm (2^16= 65536= 1 ppm).
2 solutions:
On ajoute frequency 5286874 ou
on ajoute 1 à tick et on retire frequency 1266726.
# adjtimex --frequency 5286874
 # ntpdate -b -s -p 4 mesior.obspm.fr
...
# ntpdate -b -s -p 4 mesior.obspm.fr
Résultat:
Nov 30 10:27:18 vega ntpdate[10106]: step time server 145.238.2.24 offset 0.387099 sec
Nov 30 20:43:29 vega ntpdate[11506]: step time server 145.238.2.24 offset -0.014773 sec
 Avance de 0.014773 secondes en 10h 16mn 11s soit 36971 secondes.
Ce qui donne 0.034524 secondes par jour. 34.5 millisecondes, c'est certainement inférieur à l'incertitude sur la mesure de ntpdate... On laisse ou on insiste? 5286874-26187= 5313061
On laisse la bécane en service et on attend plus longtemps pour limiter l'incertitude...
Résultat:
Nov 30 22:23:13 vega ntpdate[13697]: step time server 145.238.2.24 offset 0.002307 sec
 2 Dec 23:12:15 ntpdate[3368]: adjust time server 138.195.130.71 offset -0.130551 sec
 On décèle une avance de 130 millisecondes sur 48 heures soit 0.065 par jour. C'est le double du glissement mesuré le coup précédent parce que j'ai fait une addition au lieu d'une soustraction dans le calcul du nouveau frequency!
5313061-49304= 5263757
# adjtimex --frequency 5263757
Avec Debian, adjtimex est lancé au démarrage du système par /etc/init.d/adjtimex start
Il faut mettre les valeurs de tick et frequency dans le script. Par défaut:
TICK=10000
FREQ=0
Nouvelle mesure:
Dec  3 00:17:20 vega ntpdate[4504]: step time server 138.195.130.71 offset 0.060360 sec
# date
Tue Dec 11 23:09:57 CET 2001
# ntptrace ntp.via.ecp.fr
zen.via.ecp.fr: stratum 2, offset -0.255495, synch distance 0.03130
canon.inria.fr: stratum 1, offset -0.262705, synch distance 0.00000, refid 'GPS'
# date
Sat Dec 15 01:25:43 CET 2001
# ntptrace ntp.via.ecp.fr
zen.via.ecp.fr: stratum 2, offset -0.410169, synch distance 0.02661
chronos.cru.fr: stratum 1, offset -0.410675, synch distance 0.00000, refid 'GPS'
Avance de 410 ms en 12 jours, soit 34166 µs par jour.
Nouveau frequency: 5263757-25915= 5237842
# adjtimex --frequency 5237842
# ntpdate -b -s -p 4 ntp.via.ecp.fr


On avance encore légèrement. Cette fois j'ajuste au pif en arrondissant la valeur de frequency:
# adjtimex --frequency 5220000
# ntpdate -b -s -p 4 ntp.via.ecp.fr
Cette fois je ne dois pas être loin de la valeur optimale. Je mets les valeurs de tick et frequency dans le script /etc/init.d/adjtimex:
TICK=10000
FREQ=5220000
Maintenant qu'on sait de combien et comment il faut corriger l'horloge système, si on essayait à nouveau ntpd? Voyons où on en est avec ntptime:
# ntptime
ntp_gettime() returns code 5 (ERROR)
  time bfcda8e3.ddb9c000  Fri, Dec 21 2001 13:26:11.866, (.866116),
  maximum error 16384000 us, estimated error 16384000 us.
ntp_adjtime() returns code 5 (ERROR)
  modes 0x0 (),
  offset 0.000 us, frequency 79.651 ppm, interval 4 s,
  maximum error 16384000 us, estimated error 16384000 us,
  status 0x41 (PLL,UNSYNC),
  time constant 2, precision 1.000 us, tolerance 512 ppm,
  pps frequency 0.000 ppm, stability 512.000 ppm, jitter 200.000 us,
  intervals 0, jitter exceeded 0, stability exceeded 0, errors 0.
 Le frequency dont on parle ici, c'est le frequency de adjtimex divisé par 2^16 soit 65536.
C'est la valeur qu'on va mettre dans le fichier /var/lib/ntp/ntp.drift avant de relancer ntpd.
# /etc/init.d/ntp start
En lançant périodiquement les commandes suivantes pour surveiller frequency:
# ntptime ou
# adjtimex --print ou
# ntpq -c rv et
# cat /var/lib/ntp/ntp.drift
on constate que quand les serveurs ntp de référence sont accessibles, ntpd louvoie d'un côté et d'autre du point de réglage optimal. Quand on se déconnecte du FAI, frequency reste positionné sur le cap courant... donc on dérive jusqu'à ce que les serveurs soient de nouveau accessibles suite à quoi un coup de barre est donné dans l'autre sens. Le fichier ntp.drift est mis à jour après une demi-heure avec le frequency courant. Pas satisfaisant...


Essai de chrony.Un paquet distribué par Debian, susceptible de remplacer avantageusement ntpd dans le cas d'une connexion intermittente aux serveurs ntp de référence.
L'installation de ce paquet implique la suppression des paquets ntpd et ntpdate. Le paquet adjtimex est toléré quoiqu'il suggère ntpdate.
man chronid et man chronic ne donnent pas grand chose. La doc détaillée est dans info chrony. Il y a une doc html plus pratique à /usr/doc/chrony/chrony.html
chronyd est lancé au démarrage du système. Il est contrôlé par /etc/init.d/chrony (start, stop, restart). Mais le fichier de config /etc/chrony/chrony.conf doit être modifié, au moins pour indiquer les bons serveurs ntp.
# cd /etc/chrony
# cp chrony.conf chrony.conf.orig
Nouvelle section server:
# server 132.163.135.130  offline
server ntp.via.ecp.fr minpoll 5 maxpoll 7 offline
server ntp.obspm.fr minpoll 5 maxpoll 7 offline
server ntp0.oleane.net minpoll 5 maxpoll 7 offline
server ntp1.oleane.net minpoll 5 maxpoll 7 offline
server ntp.polytechnique.fr minpoll 5 maxpoll 7 offline
minpoll et maxpoll ont la même signification que dans ntp.conf
offline permet de démarrer  sans solliciter les serveurs (FAI non connecté).
La communication  avec chronyd se fait par chronyc, un utilitaire qui ne fonctionne qu'en mode interactif. C'est cet utilitaire qui par exemple, permet de passer de l'état initial offline à l'état online et inversement. Pour ce 2 scripts sont installés à:
/etc/ppp/ip-up.d/chrony et
/etc/ppp/ip-down.d/chrony
pour être lancés par /etc/ppp/ip-up et ip-down quand la connexion ppp s'établit ou se ferme.
On peut surveiller le fonctionnement de chrony dans syslog:
# tail -f /var/log/syslog
En lançant chronyc on obtient des renseignements sur l'état de chronyd en entrant les commandes sources, sourcestats et tracking... Après 2 ou 3 sessions sur Internet, chronyd a trouvé le bon frequency et garde le cap à peu de chose près. L'horloge du noyau est réglée. Le choix a été de faire +1 sur tick avec un frequency négatif. Le dernier frequency calculé est enregistré dans /var/lib/chrony/chrony.drift
# chronyc
chronyc> sources
210 Number of sources = 5
MS Name/IP address           Str  Poll LastRx        Last sample
========================================================================
^+ zen.via.ecp.fr              2    6    57  -1481us[+1449us] +/-   93ms
^* mesior.obspm.fr             2    5    31  +2407us[+5340us] +/-   72ms
^+ ntp0.oleane.net             2    6    27    -10ms[  -10ms] +/-   95ms
^+ ntp1.oleane.net             2    6     1  -2030us[-2030us] +/-  111ms
^+ milou.polytechnique.fr      2    7    35   +254us[+3187us] +/-  110ms
chronyc> sourcestats
210 Number of sources = 5
Name/IP          NP   NR  Span       Freq      Skew      S.D./us
================================================================
zen.via.ecp.fr   17    9  343m       0.252       0.591      5331
mesior.obspm.fr  32   14  503m       0.037       0.325      7334
ntp0.oleane.net  42   20   18h      -0.288       0.098      4650
ntp1.oleane.net  28   16  503m       0.220       0.320      5345
milou.polytechn  64   28   19h      -0.225       0.123      7155
chronyc> tracking
Reference ID    : 145.238.2.24 (mesior.obspm.fr)
Stratum         : 3
Ref time (UTC)  : Sat Dec 22 16:43:16 2001
System time     : 0.000000 seconds fast of NTP time
Frequency       : 79.595 ppm slow
Residual freq   : 0.037 ppm
Skew            : 0.392 ppm
Root delay      : 0.138275 seconds
Root dispersion : 0.003677 seconds
chronyc> quit
# cat /var/lib/chrony/chrony.drift
            -79.5577               0.3457
# adjtimex --print
         mode: 0
       offset: 0
    frequency: -1338400
     maxerror: 16384000
     esterror: 16384000
       status: 64
time_constant: 2
    precision: 1
    tolerance: 33554432
         tick: 10001
     raw time:  1009043043s 517854us = 1009043043.517854
 return value = 5
chronyd fait office de serveur ntp de strate 3 pour le réseau intérieur. Il remplace avantageusement ntpd! Une seule ombre au tableau:
De temps en temps, /etc/ppp/ip-up.d/chrony ne s'exécute pas, ce qui fait qu'on ne passe pas online quand la liaison ppp est établie. Ceci met sans doute en évidence un problème général d'exécution de /etc/ip-up. Est-ce un pb de compatibilité entre pppd et diald?
OK après avoir résolu un pb d'installation diald. Voir serveur.txt et diald.txt (ipmasq).
Encore une ombre! Quand chronyd est lancé initialement (relance du système) alors que la connexion avec le FAI n'est pas établie, il cherche à résoudre les adresses des serveurs NTP, en dépit de l'option offline. Pendant tout ce temps, il est inaccessible (ex: pas de réponse à ntptrace ou ntpdate lancé par une station du réseau local). On voit des messages d'échec dans syslog pour chaque directive server du fichier chrony.conf:
Dec 23 00:21:19 vega chronyd[422]: Invalid host/IP address at line 14
Après ça, il ne répond pas aux demandes de mise online. Pour débloquer la situation, il faut faire un restart de chrony après avoir connecté le FAI.
Pour éliminer ce problème il faut remplacer dans les directives server, les noms des serveurs NTP par leurs adresses IP. Il faudra vérifier de temps en temps si l'un des serveurs NTP n'a pas changé d'adresse IP.
Essai avec la liaison FAI chargée (téléchargement):
Aïe! chrony s'appuie sur des mesures non fiables. Le frequency s'écarte brusquement de la norme. Extrait du fichier /var/log/chrony/tracking.log:
====================================================================
 Date (UTC) Time    IP Address   St   Freq ppm   Skew ppm     Offset
====================================================================
23Dec01 11:44:50 138.195.130.71   3    -79.829      0.830 -5.271e-02
23Dec01 11:45:57 138.195.130.71   3    -79.840      1.482 -2.250e-03
23Dec01 11:47:02 138.195.130.71   3    -79.872      2.607 -1.399e-03
23Dec01 11:47:35 138.195.130.71   3    -79.977      4.714 -1.041e-03
23Dec01 11:48:10 138.195.130.71   3    -80.292      8.667 -8.503e-04
23Dec01 11:48:44 138.195.130.71   3    -81.259     16.446 -6.800e-04
23Dec01 11:49:18 138.195.130.71   3    -84.524     33.010 -1.339e-03
23Dec01 11:49:50 138.195.130.71   3    -91.450     58.440  4.573e-03
23Dec01 11:50:23 138.195.130.71   3    -97.909     76.891  1.566e-03
23Dec01 11:50:55 138.195.130.71   3   -164.053    120.908 -5.729e-02
23Dec01 11:52:34 138.195.130.71   3   -185.640     95.254 -2.463e-03
23Dec01 11:52:34 138.195.130.71   3   -180.970     87.484  3.946e-03
23Dec01 11:53:04 138.195.130.71   3   -180.068     84.220  3.454e-05
23Dec01 11:53:07 138.195.130.71   3   -175.946     86.309  2.125e-03
23Dec01 12:13:56 138.195.130.71   3   -174.910     85.017  1.701e-03
23Dec01 12:13:59 138.195.130.71   3   -166.007     90.360  1.668e-02
23Dec01 12:14:00 138.195.130.71   3   -163.705     87.688  3.997e-06
23Dec01 12:14:31 138.195.130.71   3    -89.064     47.452  1.078e-01
23Dec01 12:15:03 138.195.130.71   3    -86.032     33.386  7.555e-04
23Dec01 12:15:35 138.195.130.71   3    -85.761     27.172 -1.078e-04
23Dec01 12:16:08 138.195.130.71   3    -83.897     23.749  3.208e-03
23Dec01 12:16:40 138.195.130.71   3    -86.572     26.433 -1.981e-03
Entre 11h53 et 12h13 UTC, période sans connexion au FAI, frequency est hors norme. Si on ne s'était pas reconnecté rapidement pour le rétablir, l'horloge système serait partie dans les choux. Le tick était passé à 10002! Pour tenter d'éviter de prendre en compte des mesures non fiables on va commencer par appliquer les paramètres préconisés par la doc dans le cas d'une connexion FAI peu performante.
Surtout le paramètre maxdelay dans les directives server du fichier /etc/chrony/chrony.conf
# ntp.via.ecp.fr
server 138.195.130.71 minpoll 5 maxpoll 8 maxdelay 0.4 offline
# ntp.obspm.fr
server 145.238.2.24 minpoll 5 maxpoll 8 maxdelay 0.4 offline
# ntp0.oleane.net
server 194.2.0.28 minpoll 5 maxpoll 8 maxdelay 0.4 offline
# ntp1.oleane.net
server 194.2.0.58 minpoll 5 maxpoll 8 maxdelay 0.4 offline
# ntp.polytechnique.fr
server 129.104.30.41 minpoll 5 maxpoll 8 maxdelay 0.4 offline
Sauvegarde des données courantes de chrony dès la fermeture de la connexion ppp. Ajout des commandes dump et writertc dans le script /etc/ppp/ip-down.d/chrony:
PASSWORD=`awk '$1 ~ /^1$/ {print $2; exit}' /etc/chrony/chrony.keys`
cat << EOF | /usr/bin/chronyc
password $PASSWORD
offline
dump
writertc
EOF
exit 0
Ajout des paramètres -r -s dans la commande de lancement de chronyd, /etc/init.d/chrony:
Remplacé FLAGS="defaults" par FLAGS="-r -s"
et ajouté -- $FLAGS dans le cas de --start
start-stop-daemon --start --verbose --exec $DAEMON -- $FLAGS
Maintenant chronyd ignore bien les mesures prises quand l'accès Internet est trop chargé. Le tracking montre que le frequency se maintient autour du point idéal (79,8 environ dans notre cas).
Reste le problème de la conservation de l'heure exacte entre mise hors tension et sous tension de la machine. Comme hwclock --adjust ne donne pas satisfaction, on fait gérer l'horloge matérielle par chrony (voir la section horloge matérielle).
Malgré cela on constate que le système démarre avec un décalage de plus d'une seconde après chaque période de mise hors tension de la machine. Ceci à pour conséquence de faire sauter le frequency à la première re synchronisation avec un serveur NTP. Il faut plusieurs connexions à Internet pour voir le frequency se restabiliser autour de la valeur idéale.
La solution est de supprimer la mise à l'heure de l'horloge matérielle à partir de l'horloge système au shutdown. Dans le cas de Debian, il faut neutraliser la commande:
hwclock --systohc $GMT
dans le script /etc/init.d/hwclock.sh
(pour le détail, section horloge matérielle).
En surveillant /var/log/chrony/tracking.log, on constate encore des petits écarts autour du frequency idéal quand le skew augmente, mais le fonctionnement est globalement satisfaisant.






Horloge matérielle

(voir ci-dessus l'explication pour antares sous Slackware)
Dans le cas de vega sous Debian:
A l'arrêt et à la relance du système, est lancé /etc/init.d/hwclock.sh pour soit sauvegarder l'horloge système dans l'horloge matérielle (stop ou restart) ou restaurer l'horloge système à partir de l'horloge matérielle (start). Debian déconseille d'utiliser hwclock --adjust pour rattraper le décalage de l'horloge matérielle mais on peut décommenter cette commande dans le script si on sait ce qu'on fait (Rien d'autre que hwclock ne touche à l'horloge. Si l'horloge est manipulée il faudra supprimer le fichier /etc/adjtime).
Pour enregistrer le glissement de l'horloge matérielle dans /etc/adjtime, il faut attendre au moins un jour entre 2 commandes:
# hwclock --utc --systohc
On peut tester à blanc avec les paramètres --debug et --test. Exemple:
# hwclock --utc --systohc --debug --test
hwclock 2.4c/util-linux-2.10f
hwclock: Open of /dev/rtc failed, errno=19: No such device.
Using direct I/O instructions to ISA clock.
Last drift adjustment done at 1007591915 seconds after 1969
Last calibration done at 1007591915 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 22:47:55
Hw clock time : 101/12/06 22:47:55 = 1007678875 seconds since 1969
Time elapsed since reference time has been 0.436232 seconds.
Delaying further to reach the next full second.
Setting Hardware Clock to 22:47:54 = 1007678874 seconds since 1969
Clock not changed - testing only.
Clock drifted -2 seconds in the past 86960 seconds in spite of a drift factor of -0.000600 seconds/day.
Adjusting drift factor by -1.987121 seconds/day
Not updating adjtime file because of testing mode.
Would have written the following to /etc/adjtime:
-1.987720 1007678873 0.000000
1007678873
UTC
L'horloge matérielle avance environ de 2 secondes par 24 heures.
# hwclock --systohc --utc --debug
hwclock 2.4c/util-linux-2.10f
hwclock: Open of /dev/rtc failed, errno=19: No such device.
Using direct I/O instructions to ISA clock.
Last drift adjustment done at 1007591915 seconds after 1969
Last calibration done at 1007591915 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 22:55:11
Hw clock time : 101/12/06 22:55:11 = 1007679311 seconds since 1969
Time elapsed since reference time has been 0.430922 seconds.
Delaying further to reach the next full second.
Setting Hardware Clock to 22:55:10 = 1007679310 seconds since 1969
Clock drifted -2 seconds in the past 87396 seconds in spite of a drift factor of -0.000600 seconds/day.
Adjusting drift factor by -1.977207 seconds/day
# cat /etc/adjtime
-1.977807 1007679309 0.000000
1007679309
UTC
Pour que chrony puisse également s'occuper de l'horloge matérielle, il faut recompiler le noyau avec l'option:
 Character devices, Enhanced Real Time Clock Support (CONFIG_RTC)
 Modifier /etc/chrony/chrony.conf: décommenter la directive rtcfile et ajouter rtconutc si l'horloge matérielle conserve l'heure universelle.
# Specify the file where real-time clock data is stored.  To use this you
# must have enhanced real-time clock support compiled into your kernel.
# Uncomment the next line if you do.
rtcfile /var/lib/chrony/chrony.rtc
rtconutc
 Pour que chrony gère bien l'horloge matérielle, il ne faut plus du tout toucher à celle-ci. Dans le cas de Debian, dans le script qui contrôle l'horloge matérielle /etc/init.d/hwclock.sh, il faut non seulement ne pas valider la commande hwclock --adjust, mais il faut également neutraliser hwclock --systohc normalement exécuté au shutdown. Seul peut subsister hwclock --hctosys exécuté au démarrage du système. L'horloge matérielle peut dériver, chrony garde le glissement en mémoire et compense automatiquement quand il démarre. Pour recaler l'horloge matérielle, il faut uniquement utiliser la commande trimrtc de chronyc.
$ chronyc
chronyc> rtcdata
RTC ref time (UTC) : Fri Jan 11 23:47:58 2002
Number of samples  : 13
Number of runs     : 5
Sample span period :  23m
RTC is fast by     :     9.822327 seconds
RTC gains time at  :    12.627 ppm
chronyc> password
Password:
200 OK
chronyc> trimrtc
200 OK
chronyc> rtcdata
RTC ref time (UTC) : Fri Jan 11 23:51:22 2002
Number of samples  : 6
Number of runs     : 5
Sample span period :  110
RTC is fast by     :     0.463440 seconds
RTC gains time at  :    12.554 ppm



Avec une ancienne version de Debian (2.0), on trouve xntp3 à la place ntpd et on peut utiliser rdate à la place de ntpdate.

haut Stations WINDAUBE, antoine et remi (W95)

Installation de NTPTime Client. Version 3.0
Fichiers téléchargés:
ntptime.exe (exécutable)
ntptime.cpl (control panel)
ntptime.txt (alias .reg, modèle base de registre)
ntptime.html (page de doc)
  1. Copie de ntptime.exe à c:\windows\system
  2. Copie de ntptime.cpl à c:\windows\system
  3. Lancement du panneau de contrôle de NTPTime via le panneau de configuration pour configurer la petite bête.
  4. Lancement de ntptime.exe
Le panneau ne se lance pas sur la bécane de Rémi (?). Contourné le problème en éditant le fichier ntptime.txt avec les valeurs et les paramètres désirés. Renommé en ntptime.reg et lancé par double clic pour entrer dans la base de registre. C'est bon quand même. Satisfaisant.


REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\ntcli\NTPTime\3.0]
"NTPServerName"="vega.bd.fr"
"LogDirectory"="C:\ntptime"
"WriteLogEntries"=dword:00000001
"LogFileCount"=dword:00000007
"WaitForRAS"=dword:00000000
"RASPollMilliseconds"=dword:00000000
"NTPPollMilliseconds"=dword:001b7740
"RunOnce"=dword:00000000
"MaxAdjustSeconds"=dword:00000000