31 wrote: > > siempre lo he puesto en la bios, pero cuando se cambia la hora tengo que > cambiarlo, �hay > forma de que se cambie automaticamente?, ademas mi bios adelanta un poco, y > tambi�n he oido > que hay una forma de poner en hora el reloj de linux que toma en cuenta los > adelantos cada > vez que se pone en hora y ajusta solo el reloj, haciendo que cada vez sea mas > preciso �es > verdad?
Primero un poco de teor�a: En Linux hay dos relojes: el de la BIOS (o el de CMOS, o RTC, o reloj hardware: tiene muchos nombres) y el del sistema. El que importa es el del sistema, pero al arrancar el kernel no sabe qu� hora es. Para que el sistema sepa la hora el primer programa que lanza el kernel (el programa init) se la pregunta al reloj hardware inmediatamente despu�s del arranque (el trabajo sucio lo hace /etc/rcS.d/S50hwclock.sh --> /etc/init.d/hwclock.sh, que se instala gracias al paquete base/util-linux). Por entonces el kernel no sabe nada de variables del sistema tipo TZ. Lo �nico que necesita saber es si el reloj hardware mantiene una hora local o la hora universal (GMT, UTC). Eso lo sabe mirando qu� valor tiene la variable GMT en el fichero /etc/default/rcS (fichero que creo que se crea cuando instalas Debian por primera vez y te pregunta entre otras cosas qu� tipo de hora mantiene tu reloj hardware). Entonces pone la hora del sistema como la hora del reloj hardware. Cuando durante el arranque aparece en pantalla Local time: Mon Nov 15 19:42:10 CET 1999 es que el hwclock.sh ha actuado. Desde entonces tienes el reloj del sistema con la misma hora que el reloj hardware. Pero cada uno de ellos se mueve a diferente velocidad porque tienen distintos mecanismos de funcionamiento. El hardware funciona con un oscilador de cuarzo o lo que sea, y el de sistema mediante una interrupci�n de tiempo (la t�pica timer interrupt que forma parte del est�ndar ISA). S�lo vuelven a coincidir los dos relojes cuando se apaga el sistema y entre otros se ejecuta el script /etc/init.d/hwclock.sh con la opci�n stop: entonces la hora del sistema se guarda en el reloj hardware, y al cabo de pocos segundos tienes el ordenador apagado. Este sistema de sincronizaci�n presupone que justo antes de apagar el ordenador, la hora del sistema es m�s fiable que la hora del reloj hardware. Con el sistema en marcha puedes modificar cualesquiera de estos dos relojes, aunque no es aconsejable modificar el reloj del sistema con el comando date porque entonces haces que haya discontinuidades en la hora (aunque no s� por qu� eso es tan malo). El reloj hardware se puede modificar con el comando hwclock cada vez que quieras. Para eliminar errores sistem�ticos del reloj hardware lo mejor es usar una fuente fiable de la hora (creo que es m�s fiable llamar a informaci�n horaria que usar tu reloj de pulsera, pero no lo he comprobado) para poner el reloj hardware a la hora que sea con "hwclock --set ..." (has de ser root para poner el reloj), y hacerlo cuando enciendas el ordenador y bastantes horas despu�s estando enchufado (eso es para que no se ejecute /etc/init.d/hwclock.sh con la opci�n stop y te joda el invento). As�, tendr�s en el fichero /etc/adjtime la informaci�n necesaria para poner siempre el reloj hardware en hora con un simple "hwclock --adjust". Sin embargo, esto no funciona si en alg�n momento apagas el ordenador, se ejecuta /etc/init.d/hwclock.sh con la opci�n stop (que te hace un hwclock --systohc), y por una de esas la hora del sistema no es exacta. Entonces, en /etc/adjtime tendr�as la informaci�n para ajustar el reloj hardware al reloj del sistema, lo cual es un problema si el reloj del sistema no es suficientemente fiable. Por eso, creo que la soluci�n es tener siempre el reloj del sistema funcionando perfectamente. Pero no es aconsejable poner el reloj del sistema con el comando date porque eso provocar�a una discontinuidad en la hora, y adem�s habr�a que repetirlo continuadamente cada vez que se observara un atraso o adelanto considerable. Por ello es mejor usar el comando adjtimex (paquete admin/adjtimex) que cambia la hora del sistema de forma progresiva (suave) y sistem�tica (siempre). Para ello modifica ciertas variables del kernel (no confundir con la variable de entorno TZ) que se usan para determinar la hora: tick y frequency para que el reloj del sistema se ajuste a una fuente externa. Dependiendo de la fuente externa se usa con unas opciones u otras. Y ahora la pr�ctica: Antes que nada hay que saber si el reloj del sistema usa GMT (o UTC). Si en /etc/default/rcS la variable GMT es "" entonces la hora es local, pero si GMT es "-u" entonces hay que usar la opci�n -u en los comandos en que se escriba [-u]. Adem�s, si la hora del sistema es local, hay que asegurarse de que el sistema conoce el timezone. El timezone viene definido en el fichero /etc/timezone, y/o en la variable de entorno TZ. Adem�s has de tener los comandos hwclock (en el paquete base/util-linux) y netstd (en el paquete net/netstd). Las fuentes externas (extenas al sistema) de hora pueden ser: el reloj hardware, un reloj que no pueda leer directamente sino a trav�s de la informaci�n que le proporcione una persona que mira ese reloj (un reloj de pulsera, o de servicio telef�nico, o el del teletexto), y un reloj en un ordenador servidor de tiempo accesible via internet. Por ello, seg�n tus posibilidades tienes que elegir alguna de estas soluciones: Y ahora la pr�ctica: a) Un ordenador completamente aislado del mundo: a.1: Tras instalar el paquete admin/adjtimex, lo primero es borrar todos los ficheros antiguos con datos generados autom�ticamente (quieres tener pleno control): # cat <<EOF >/etc/adjtime > 0.0 0 0.0 > EOF # rm /var/log/clocks.log a.2: C�gete un buen reloj (de pulsera, de pared, de lo que sea) o pon el teletexto de alguna cadena de televisi�n o llama a informaci�n horaria. Teclea "adjtimex [-u] -w <enter>" (la opci�n -u s�lo hay que ponerla si trabajas con hora universal, y no con hora local) y vuelve a pulsar <enter> cuando sepas la hora exacta (el segundero del reloj marca exactamente 00, por el tel�fono suena la se�al horaria "pip", ...) entonces di qu� hora era cuando has pulsado <enter> y qu� error adjudicas a este tiempo (cuanto tiempo pasa desde que es la hora hasta que pulsas <enter>: yo pongo 0.1 segundos: para estimar tus reflejos y capacidad y anticipaci�n te sugiero que pongas un cron�metro en marcha e intentes pararlo cuando marque 10 segundos exactos). Cada cierto tiempo (media hora, una hora) vuelve a hacer "adjtimex [-u] -w" (-u si el reloj del sistema va en UTC, sin -u si es hora local) para darle informaci�n de la hora que es, y entonces "adjtimex -r" para mostrar las estimaciones (ajuste por m�nimos cuadrados) de los errores sistem�ticos del reloj del sistema y del reloj hardware. a.3: Entonces, cuando tenga suficientes datos buenos, en la informaci�n que te da "adjtimex -r" aparecer� el "suggested tick" y el "suggested freq". Imagina que te sale: least-squares solution: cmos_error = -215 +- 11 ppm suggested adjustment = 18.5921 sec/day sys_error = 785 +- 11 ppm suggested tick = 9992 freq = 963288 note: clock variations and unstated data errors may mean that the least squares solution has a bigger uncertainty than estimated here entonces, edita el fichero /etc/rc.boot/adjtimex y cambia las l�neas TICK=10000 FREQ=0 por las l�neas TICK=9992 FREQ=963288 para que las variables del kernel tengan los valores apropiados cuando arranques de nuevo. Adem�s puedes fijarte en cu�l de los dos relojes es mejor: en este caso el de harware (cmos) tiene un error menor (215 partes por mill�n = 19 segundos al d�a) que el del sistema (785 partes por mill�n = 68 segundos al d�a). Adem�s tendr�s que hacer "adjtimex -tick 9992 -frequency 963288" para eliminar las variaciones sistem�ticas del reloj del sistema hasta que no lo apagues de nuevo. a.4: Una vez eliminadas las variaciones sistem�ticas (systematic drift) hay que eliminar el error sistem�tico constante. Para ello, puedes hacerlo con: # cat <<EOF > /etc/adjtime > 18.5921 0 0.0 (el 18.5921 aparec�a haciendo "adjtimex -r") > EOF # date [-u] --set "22:32:50" (la hora que sea cuando teclees <enter>) # hwclock [-u] --systohc a.5: De esta forma tendr�s los dos relojes siempre sincronizados a tu fuente externa y sincronizados entre s�. Si detectas que la sincronizaci�n falla al cabo de unos d�as, vuelve a hacerlo todo desde el punto a.1. b) Un ordenador que tiene una conexi�n intermitente a internet (por ejemplo, si usas modem y s�lo lo enchufas unos pocos minutos al d�a: al empezar la jornada laboral, y al terminarla para leer el correo electr�nico) b.1: Exactamente igual que en a.1. b.2: Es igual que en el apartado a) salvo que en vez de usar una fuente externa manual usas un servidor de tiempo. Yo en la facultad uso el servidor del campus que est� en la IP 147.156.1.3. Entonces, en vez de "adjtimex [-u] -w" de antes usas "adjtimex [-u] --host 147.156.1.3". Ejecutas este comando un par de veces con una separaci�n de unas horas, y "adjtimex -r" te dar� unos valores muy precisos del systematic drift (variaci�n sistem�tica) de los relojes hardware y del sistema. b.3: Exactamente igual que en a.3 b.4: El error sistem�tico constante de ambos relojes se elimina muy f�cilmente con # cat <<EOF > /etc/adjtime > 18.5921 0 0.0 (el 18.5921 aparec�a haciendo "adjtimex -r") > EOF # netdate 147.156.1.3 # hwclock [-u] --systohc b.5: Los relojes hardware y del sistema est�n sincronizados entre s� y con el reloj del servidor de tiempo. Si al cabo de unas semanas ves que se producen variaciones sistem�ticas, vuelve a empezar desde el punto b.1. c) Un ordenador con una conexi�n permanente a internet (como lo que tengo en la facultad: una red local en todo el campus con la que estoy siempre conectado) c.1: Ahora no se necesita el paquete adjtimex, pues es mejor usar el demonio xntpd. Para ello instala el paquete net/xntp3. Cuando lo configures (le tendr�s que decir cu�l es tu servidor de tiempo, por ejemplo 147.156.1.3 para los ordenadores de la Universidad de Valencia) dile que quieres ejecutar el comando ntpdate antes de ejecutar el demonio xntpd cuando el sistema arranca, con lo que siempre tendr�s una buena hora de sistema desde el momento del arranque. c.2: Para ver como funciona todo el cotarro sin tener que esperar al siguiente arranque puedes hacer: # /etc/init.d/xntp3 start # hwclock [-u] --systohc c.3: Y ya no tendr�s que preocuparte nunca m�s de que el reloj del sistema tenga una variaci�n sistem�tica, salvo que el servidor de tiempo se caiga o te corten el cable Ethernet, o alguna otra desgracia. c.4: Adem�s, el script /etc/init.d/hwclock.sh, que se ejecuta al arrancar y al apagar el sistema te asegura que el apagar el sistema el reloj hardware se actualizar� con la hora del sistema (que es perfecta gracias a xntpd), y otros SOs que usan este reloj (como Mierdows 9x y TOS) se beneficiar�n de la potencia de Linux. F�jate que al apagar el sistema aparece un mensaje como �ste: CMOS clock updated to Mon Nov 15 23:43:44 CET 1999. PS: Y hablando de la hora que es: he tardado CUATRO HORAS en escribir este email, me he quedado sin cenar, sin ver Periodistas, y como no me d� prisa en salir seguro que me atacan los perros de seguridad del campus. -- 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
