Juan Leseduarte wrote:
> Supongo que consiste en el mensaje que ya enviaron a esta misma lista hace un
> tiempo. Era realmente muy interesante, y era espec�fico para Debian, ya que
Como supongo que hablas del email que escrib� en noviembre: �muchas
gracias! El documento En-Hora-Como.html no tiene nada que ver con mi
email de noviembre.
> est� basado en los scripts que tiene por defecto Debian. No obstante, creo
> que hay un fallo (ojo, en los scripts de Debian, no en el documento). Me
> explico: La idea del m�todo es: Al arrancar Debian, el reloj del sistema
> pregunta al reloj de hardware la hora que es, �ste responde, pero el el
> sistema no se la cree, si no que dice: bueno como que desde la �ltima vez que
> se apag� Debian ha pasado tanto tiempo, y como s� ( porque lo dice as�
> /etc/adjtime ) que el reloj de hard necesita un ajuste de X segundos por d�a,
> la hora que doy por buena es:
>
> hora que da el reloj de hard + X*n�mero de d�as (en decimal) que han pasado.
Correcto: todo ello lo hacen las siguientes dos l�neas del fichero
/etc/rcS.d/S50hwclock.sh -> ../init.d/hwclock.sh:
hwclock --adjust $GMT
hwclock --hctosys $GMT
La primera "arregla" la hora del reloj hardware bas�ndose en cu�nto
tiempo lleva el reloj hardware sin ser corregido y su atraso X. Estos
dos datos se obtienen de /etc/adjtime. Este fichero contiene como datos:
1) atraso (en segundos/d�a, si el reloj hardware adelanta entonces el
atraso es negativo), 2) fecha de la �ltima correcci�n (en segundos desde
nochevieja de 1969), 3) un cero, 4) fecha de la �ltima calibraci�n (en
segundos desde nochevieja de 1969).
Aqu� es importante distinguir entre calibraci�n y correcci�n. La
correcci�n es cuando se pone el reloj hardware a una hora, mientras que
en una calibraci�n esta hora se considera fiable y se puede usar para
c�lculos posteriores. El reloj hardware se calibra con las opciones
--systohc y --set. La opci�n --adjust no lo calibra, sino que s�lo lo
corrige. Por tanto, en terminolog�a de conjuntos puede decirse que
correcci�n = ajuste U calibraci�n (U=uni�n).
Sabiendo qu� hora marca el reloj hardware ahora, h1 (en s), qu� hora
marcaba en su �ltima correcci�n, h0 (en s), y el atraso X (en s/d�a),
puede calcularse qu� hora h es ahora (en s). La f�rmula que hwclock usa
para la opci�n --adjust es inch=FLOAT((h1-h0)*X/86400+0.0), con FLOAT
una macro para convertir n�meros decimales en enteros de forma que si
x=FLOAT(y) entonces x<=y<x+1, x entero. Si inch es mayor que 0 o menor
que -1 entonces aplica h=h1+inch y actualiza /etc/adjtime de manera que
su segundo campo (fecha de �ltima correcci�n) sea h.
Una vez que el reloj hardware est� corregido, la segunda l�nea pone la
hora del sistema a lo que marque el reloj hardware.
Cuando el sistema se resetea, uno de los cuatro �ltimos scripts que se
ejecutan es /etc/rc6.d/S25hwclock.sh con la opci�n stop. Entonces se
guarda la hora que tenga el sistema en el reloj hardware hasta el
momento en que se vuelva a encender el sistema (al cabo de unos
segundos, horas o d�as). Esto lo hace con la l�nea:
hwclock --systohc $GMT
La opci�n --systohc ejecuta una calibraci�n del reloj hardware (usando
como fuente la hora del sistema). Adem�s de cambiar la hora del reloj
hardware, modifica los campos 1, 2 y 4 del fichero /etc/adjtime. Los
campos 2 y 4 los pone a la hora actual (en segundos tras la medianoche
de 1969). El campo 1 lo calcula de una forma totalmente INESPERADA y que
no se ajusta a lo que comenta el manual de hwclock. En concreto el
manual dice:
Every time you calibrate (set) the clock (using --set or
--systohc ), hwclock recalculates the systematic drift
rate based on how long it has been since the last calibra�
tion, how long it has been since the last adjustment, what
drift rate was assumed in any intervening adjustments, and
the amount by which the clock is presently off.
Sin embargo, el c�digo fuente de hwclock para las opciones --systohc y
--set llaman a una funci�n (adjust_drift_factor) con cuatro argumentos:
1) puntero a estructura con los datos del fichero /etc/adjtime, 2) hora
a la que hay que poner el reloj hardware, 3) y 4) hora que marca el
reloj hardware. Los comentarios a esta funci�n dicen que:
We assume that the user has been doing regular drift adjustments
using the drift factor in the adjtime file, so if <nowtime> and
<clocktime> are different, that means the adjustment factor isn't
quite right.
lo cual es un poco sospechoso, porque no dice que expl�citamente
compruebe que ha pasado un tiempo despreciable desde la �ltima
correcci�n. Dice que supone que antes de llamar al hwclock (--set o
--systohc) el usuario (root) ha ido llamando a hwclock regularmente con
--adjust. La prueba de todo ello es que lo que se calcula como
factor_adjust es 86400 * (hora real - hora del hardware) / (hora del
hardware - hora de la �ltima calibraci�n). Si el usuario no ha ejecutado
(como root) "hwclock --adjust" nunca desde el arranque del sistema,
entonces el factor_adjust calculado es el nuevo drift_factor. Si el
usuario ha ejecutado "hwclock --adjust" (y realmente el reloj hardware
se ha corregido, pues no se corrige si la correcci�n inch es 0 � -1
segundos) inmediatamente antes de hacer "hwclock --set" o "hwclock
--systohc" entonces el factor_adjust calculado es realmente una
correcci�n al drift_factor que se ha aplicado con --adjust.
Y eso es lo que la funci�n supone, pues unas l�neas m�s abajo tiene:
adjtime_p->drift_factor += factor_adjust;
> Lo que a yo observo es que el valor de X se actualiza mal. Este valor (el
> primer n�mero que aparece en /etc/adjtime) deber�a ser m�s o menos el mismo.
> Sin embargo observo que los ajustes se van acumulando, y si ten�a al principio
> (el 10 de marzo pasado) como "suggested adjustment" = -0.3951 sec/day (por
> cierto nada m�s hacer hwclock --systohc ya cambi� algo) ahora voy por:
> -12.114908
Por lo tanto, Juan Leseduarte ha comprobado experimentalmente que la
funci�n adjust_drift_factor no funciona como todos esper�bamos (como
hab�amos le�do en el man de hwclock), y efectivamente actualiza mal el
valor de X.
> �Alguien me puede corregir si estoy equivocado? �Nadie ha observado esta
> irregularidad? �Ser�a un error de los scripts o de hwclock?
Parece ser que no est�s equivocado. Me gustar�a haber observado esta
irregularidad, pero uso el paquete xntp3 para mantener la hora del
sistema sincronizada con servidores NTP (demonio xntpd lanzado tras
haber puesto el reloj del sistema con ntpdate) y por tanto paso
ol�mpicamente de lo que dice el reloj hardware.
Con respecto a la �ltima pregunta, yo dir�a que la culpa la tiene una
falta de entendimiento entre el programador de hwclock y el escritor del
manual de hwclock. Supongo que el que program� el script hwclock.sh de
init ([EMAIL PROTECTED]) se ley� (como yo) s�lo el manual de hwclock, y
no se puso a comprobar el c�digo fuente. Por ello, la forma r�pida de
solucionarlo ser�a incluir una l�nea "hwclock --adjust $GMT" antes de
"hwclock --systohc $GMT" del fichero /etc/init.d/hwclock.sh.
Sin embargo, la mejor forma de solucionarlo ser�a modificar la funci�n
adjust_drift_factor. Si llamamos now a la hora verdadera ahora, hw a
lo que marca el reloj hardware ahora, hw1 a lo que marcaba el reloj
hardware DESPU�S de hacer el �ltimo hwclock --adjust, y hw0 a lo que
marcaba el reloj hardware DESPU�S de hacer el �ltimo hwclock --systohc
(o --set v�lido), y X0 al drift_factor viejo, he demostrado (la
demostraci�n ocupa un folio, se la puedo mandar por fax a quien la
quiera) que la cantidad que hay que sumar a X0 (en segundos/d�a) para
obtener un drift_factor actualizado es:
incX=(now-hwa)*(86400+X0)/(hwa-hw0)
siendo hwa=hw+(hw-hw1)*X0/86400 lo que marcar�a el reloj hardware si se
hiciera un --adjust justo antes del --systohc � --set.
En conclusi�n, habr�a que cambiar las siguientes l�neas de la funci�n
adjust_drift_factor en hwclock.c:
const float factor_adjust =
((float) (nowtime - hclocktime)
/ (hclocktime - adjtime_p->last_calib_time))
* 24 * 60 * 60;
por:
const float hclocktimeadjusted = hclocktime + ((float) hclocktime -
adjtime_p->last_adj_time) * adjtime_p->drift_factor / 86400;
const float factor_adjust = (nowtime - hclocktimeadjusted) * (86400 +
adjtime_p->drift_factor) / (hclocktimeadjusted -
adjtime_p->last_calib_time);
Supongo que todo esto le interesar�a al mantenedor del paquete
util-linux (donde est� el programa hwclock y el script hwclock.sh) y
habr�a que mandar un aviso de bug a debian. Sin embargo, no es algo que
me interese especialmente (pues yo paso del hwclock). Si quer�is
vosotros mandar un bug report a Debian con la informaci�n que os doy,
adelante, pero me temo que no servir� de nada: he visto la "Debian Bug
report logs" del paquete util-linux y �hay bugs en fase "outstanding"
desde hace m�s de dos a�os!
> Actualmente voy 1 minuto y 32 segundos atrasado. Comparado con el
desmadre que
> ten�a antes est� bastante bien, pero creo que no es del todo satisfactorio.
> Sobre todo teniendo en cuenta que para hacer el ajuste con el servidor de hora
> de SLUG tuve el ordenador encendido todo un fin de semana para hacer 2
> adjtimex bien separados y tener un calibrado fiable.
Yo pasar�a del adjtimex (purgar�a el paquete), y pondr�a la hora con un
"ntpdate -b -s hora.rediris.es" (hora.rediris.es es una servidor NTP de
tipo "stratum 1") en el script /etc/init.d/xntp3 que se crea al instalar
el paquete xntp3. Supongo que el demonio xntpd aprovechar� los pocos
momentos en que tengas conexi�n internet para ajustar la hora del
sistema. Te voy a dar una receta para poner a punto tu sistema (has de
ser root) sin que tengas que tener el ordenador encendido.
# adjtimex -tick 10000 -frequency 0 (esto resetea las variables del
kernel)
# dpkg --purge adjtimex
# dselect
Selecciona e instala el paquete xntp3 con la opci�n de que ejecute
ntpdate al arrancar el sistema. Como servidor NTP puedes decirle que use
hora.rediris.es, que est� en Madrid, o cualquier otro que conozcas
# echo "0.0 0 0.0" > /etc/adjtime
# . /etc/default/rcS
# [ "$GMT" = "-u" ] && GMT="--utc" (para tener la variable GMT a su
valor correcto)
# /etc/init.d/xntp3 stop ; /etc/init.d/xntp3 start
# hwclock --systohc $GMT
# joe /etc/init.d/hwclock.sh (joe o cualquier otro editor de texto)
La l�nea 32 deber�a quedar as�:
"hwclock --adjust $GMT; hwclock --systohc $GMT # modificada el
24-abr-2000"
# mv /etc/init.d/hwclock.sh /etc/init.d/hwclock.sh.dpkg-dist
Ahora s�lo has de acordarte de no hacer nunca ning�n hwclock (el sistema
ya lo har� por ti al arrancar y al apagar el ordenador). Si no tienes
una conexi�n continua a internet no s� si xntpd aprovechar� los momentos
en que hay conexi�n para comprobar el reloj. Si al cabo de unos d�as
crees que no funciona como es debido siempre puedes comprobar la hora
con:
$ /usr/sbin/ntpdate -q hora.rediris.es ; date (no hace falta que seas
root)
Si la hora del sistema se ha ido demasiado puedes ponerla bien con:
# /etc/init.d/xntp3 stop ; /etc/init.d/xntp3 start (has de ser root)
Espero que con el cambio al hwclock.sh el primer n�mero de /etc/adjtime
se mantenga m�s o menos constante, y que con xntp3 la hora se te
mantenga correctamente.
--
Conrado Badenas <[EMAIL PROTECTED]>
PhD student | Assistant Lecturer
Department of Thermodynamics | Department of Optics
---------------------------------------------------
Faculty of Physics. University of Valencia
c/. Dr. Moliner, 50
46100 Burjassot (Valencia) - SPAIN
