On Wed, Feb 12, 2003 at 10:40:18AM +0000, Yves Rutschle wrote:
On Tue, Feb 11, 2003 at 08:43:44PM +0100, Gabriel Paubert wrote:
Curieux. Ce que tu dis me rappelle effectivement quelque
chose, mais il semble que tout soit g�r� par le m�me pilote
(/dev/rtc).
Non, le PIT est directement g�r� par le code dans
arch/i386/kernel/time.c et n'a rien � voir avec la RTC.
Aaaah �a y'est, j'ai compris.
En fait, je n'aurais jamais du parler des compteurs dans mon
premier message, car toute cette histoire ne concerne que la
RTC.
Ben oui, mais tu m'as forc� � r�agir.
La pr�cision vient du fait qu'elle est d�riv�e du quartz
32768 Hz charg� de garder l'heure qui est en g�n�ral un oscillateur de
meilleure qualit� que l'oscillateur (toujours d�riv� d'un fr�quence
d'origine NTSC vers 14.38 MHz et divis�e par 12) qui sert au reste
du syst�me.
Comment se fait-il que l'on consid�re en g�neral l'horloge
syst�me comme �tant plus fiable que l'horloge RTC?
En quel sens plus fiable?
man hwclock:
The Adjust Function
The Hardware Clock is usually not very accurate.
However, much of its inaccuracy is completely
predictable - it gains or loses the same amount of time
every day. This is called systematic drift. hwclock's
"adjust" function lets you make systematic corrections to
correct the systematic drift.
Le reste de la discussion sugg�re que l'horolge syst�me est
plus fiable (d�rive moins) que la RTC:
C'est faux en g�n�ral, mais �a d�pend fortement de la carte m�re
comme la suite va le d�montrer.
il faut r�-ajuster
l'horloge RTC a partir de la d�rive mesur�e sur l'horloge
syst�me. Il n'est pas fait mention de NTP dans la
discussion, donc je suppose que l'horloge syst�me marche
toute seule (donc, bas�e sur... le PIT?).
Hmmm, apr�s l'avoir relu, je dirai qu'ils sont dans le flou
artistique. Pour plus de d�tails, il faut aussi voir adjtimex
et en particulier /usr/share/doc/adjtimex/README.gz
Et si ils mentionnent NTP, dans la section "Automatic Hardware Clock
Synchronization By the Kernel". Mais bon d�s que tu as NTP, hwclock
et adjtimex ne servent � rien.
Juste pour donner un exemple, prenant 4 machines au hasard ici,
voil� ce que j'ai pour /etc/ntp.drift (toutes nos machines sont
sous NTP, on n'est pas dans l'astronomie pour rien ;-)):
-36.830
-22.596
15.358
24.235
et une s�rie de machines d'acquisition (Motorola PPC sous Linux
aussi, pas de disque, racine sur NFS):
-7.708
11.486
5.157
-7.629
-10.210
-0.483
6.158
4.650
0.323
-7.272
0.791
2.772
-3.380
La premi�re machine, notre serveur principal, donnerait en gros
3 secondes par jour d'erreur, soit une erreur de 1Hz sur un quartz
32768 Hz. Un chip courant de RTC (DS12C887 de Maxim) est donn�
pour +- 2 secondes/jour (entre 0 et 70 degr�s si je me souviens bien),
soit 24 ppm. Les autres PC sont assez mauvais aussi, en fait bien
pire que l'erreur typique d'une RTC. Par contre, les Motorola MVME
sont pas si mauvaises (ce que j'avais vu pr�c�demment c'est que
la valeur de ntp.drift varie moins sur les Motorola, mais leur horloge
n'est pas d�riv�e de la base NTSC des PC).
Un oscillateur � quartz correctement ajust� fait bien mieux que
2 secondes/jour, surtout dans une salle climatis�e, mais ce n'est
pas ce qu'on trouve sur un PC ou on minimise a) le co�t, b) le
co�t, et c) le co�t.
La page man suppose-t-elle que l'on utilise NTP par
ailleurs, ou bien est-elle �crite en avec de meilleures
architectures en t�te?
Je ne sais pas. A mon avis elle correspond bien a une machine
d�connect�e ou connect�e � un r�seau lent (RTC) et ne fonctionnant
pas en permanence: faire un hwclock --adjust suivi de --hctosys
au d�marrage et �teindre au bout de quelques heures doit donner des
r�sultats satisfaisants (remarque qu'ils ne parlent pas de faire un
systohc).
Hmm, d�couvrant /usr/share/doc/util-linux/README.Debian.hwclock.gz,
ils disent juste le contraire de la man page. Mais je ne pense
pas que la m�thode Debian de faire un hwclock --systohc soit la
bonne non plus. En fait je ne vois pas de configuration dans
laquelle elle puisse m'�tre utile. Bon, il faudra que je m'en souvienne
pour les machines Motorola (que je vais passer bient�t sous Debian).
Mais franchement, le PIT est tellement archa�que qu'on est en train
d'essayer de le remplacer par autre chose (cyclone, HPT, etc...), qui
donnent plus de bits en un seul acc�s et n'ont pas besoin de pr�cautions
suppl�mentaires (spinlock) juste pour aller lire un compteur.
Le PC, toujours bas� sur des technologies des ann�es 70 :-)
Oh, oui. Et c'est pas l'Opteron/Athlon64 qui va changer �a. Franchement
les p�riph�riques d'Intel sont les pires, surtout les controlleurs
d'interruption, mais pourquoi faire simple quand on peut faire
horriblement complexe?
Gabriel
