Re: a quoi sert /proc/sys/dev/rtc/max-user-freq ?
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
Reply to: