[opensuse-es] Re: [opensuse-translation-es] Undisciplined Local Clock (LOCAL)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2007-12-02 a las 22:45 +0100, Camaleón escribió: (permíteme que cambie a la lista general)
Pues hay un Bug enla 10.3 que me afecta que hace que el reloj del sistema se desfase tanto que llega un momento que el ntpd abandona y lo da por imposible.
Podrías desactivar el reloj "rebelde" (undisciplined) y que trabaje sólo con los servidores externos :-?
No, el reloj local no se puede desactivar nunca, es el principal. Es el reloj del sistema, que se puede consultar cientos de veces por segundo. Eso no se puede hacer con uno de red. El reloj del sistema puede ir independiente, que es lo que hemos hecho toda la vida, o se puede ajustar de vez en cuando con otro externo, que es lo que hace el ntp.
Ese reloj "rebelde" no lo veo útil salvo que necesites un equipo de la red que se encargue de difundir la hora al resto y que por el motivo que sea no disponga de conexión a la red externa para sincronizar. En cualquier otro caso no le veo mucho sentido su uso si da problemas.
No es cuestión de que tenga sentido o no, ese es el reloj del sistema y no se puede cambiar, es central al kernel. A todo kernel de todo ordenador de toda arquitectura... fíjate si hay cosas hechas en común. Si el reloj del sistema no funciona estamos jo... jorobados, eso.
Llego a tener retrasos de media hora en una hora y media, y suele ocurrir cuando no estoy mirando (comiendo, por ejemplo).
¿Y que el ntpd no pueda actualizar la hora por un desfase de 30 minutos no es otro "bug"? Como si el reloj del sistema le dice que estamos a "5 de septiembre de 1995"... ¿tiene alguna limitación en ese aspecto (en desfase de atraso o adelanto de hora?
Es una caracteristica a propósito y documentada. Ten en cuenta que el ntp hace un ajuste lento: en vez de poner en hora el reloj diciendole "ahora son las cuatro" lo que hace es decirle que acelere un poquito para que alcance al reloj real del mundo, y cuando lo alcanza vuelve a reducir su velocidad hasta que ambos van a la par. Y esa aceleración o reducción también es lenta. El objetivo es que no haya variaciones bruscas ni en la frecuencia del reloj ni en la hora que muestre. Pero si la hora se le va de las manos pues entonces abandona, porque no va a poder ajustarla, o tardaría dias. De hecho ese es el criterio, las horas o días que tardaría en sincronizar, aunque se defina en terminos de 20 minutos de desfase. Claro está que se pueden tocar los margenes y las velocidades en la configuración, pero ese no es el problema de fondo... Ahora bien, si reinicializas el servicio (rcntp restart) el script encargado primero llama a ntpdate, que ese sí que pone el reloj en hora de golpe, y luego arranca el daemon. Y pueden pasar cosas curiosímas... si adelantas el reloj media hora puede saltarte el salvapantallas porque hace media hora que no tocas el PC. Si el postfix ha enviado un correo al amavis y está esperando respuesta, cree que no va a haber respuesta porque lleva esperando media hora, y devuelve el correo por no enviable, por ejemplo. Y cuando el amavís se lo entrega dos segundos más tarde, se vuelve a a armar otra gorda. Y si atrasas el reloj ni te cuento. En algunos casos se pueden colgar las X... - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHU15ltTMYHG2NR9URAj4DAJ4sGn65RDa25TNkaaOoynD5YJLjEQCgggtx vmVwl9aBHxJrhUrw/89FQzE= =vuak -----END PGP SIGNATURE-----
El 3/12/07, Carlos E. R. escribió:
No, el reloj local no se puede desactivar nunca, es el principal. Es el reloj del sistema, que se puede consultar cientos de veces por segundo. Eso no se puede hacer con uno de red.
Quería decir que probaras a comentar (desactivar) en /etc/ntpd.conf el reloj indisciplinado para que el demonio ntp no lo use a la hora de sincronizar. Así le fuerzas a usar sólo la sincronización con servidores de tiempo remotos. No creo que tenerlo activado sea obligatorio ¿no? No es el reloj del sistema, y no todo el mundo tiene instalado un servidor de sincronización de tiempo por lo que no lo veo necesario :-?
El reloj del sistema puede ir independiente, que es lo que hemos hecho toda la vida, o se puede ajustar de vez en cuando con otro externo, que es lo que hace el ntp.
Correcto.
No es cuestión de que tenga sentido o no, ese es el reloj del sistema y no se puede cambiar, es central al kernel. A todo kernel de todo ordenador de toda arquitectura... fíjate si hay cosas hechas en común. Si el reloj del sistema no funciona estamos jo... jorobados, eso.
¿Dices que el reloj idisciplinado es el reloj del sistema? :-? No lo entiendo. A ver, ¿no es posible configurar ntp para que use sólo servidores externos? Que ntp no pueda sincronizar la hora no quiere decir que se desajuste el reloj del sistema, vaya, sencillamente tendrá segundos de desfase, pero nada más...
Es una caracteristica a propósito y documentada.
Ah, vaya...
Ten en cuenta que el ntp hace un ajuste lento: en vez de poner en hora el reloj diciendole "ahora son las cuatro" lo que hace es decirle que acelere un poquito para que alcance al reloj real del mundo, y cuando lo alcanza vuelve a reducir su velocidad hasta que ambos van a la par. Y esa aceleración o reducción también es lenta.
O.k.
El objetivo es que no haya variaciones bruscas ni en la frecuencia del reloj ni en la hora que muestre. Pero si la hora se le va de las manos pues entonces abandona, porque no va a poder ajustarla, o tardaría dias. De hecho ese es el criterio, las horas o días que tardaría en sincronizar, aunque se defina en terminos de 20 minutos de desfase.
Claro está que se pueden tocar los margenes y las velocidades en la configuración, pero ese no es el problema de fondo...
Pues sí que le afecta el tiempo a los sistemas... entiendo que haya problemas con los programas que dependen, pero el sistema "per se" no debería verse afectado de igual forma.
Y pueden pasar cosas curiosímas... si adelantas el reloj media hora puede saltarte el salvapantallas porque hace media hora que no tocas el PC. Si el postfix ha enviado un correo al amavis y está esperando respuesta, cree que no va a haber respuesta porque lleva esperando media hora, y devuelve el correo por no enviable, por ejemplo. Y cuando el amavís se lo entrega dos segundos más tarde, se vuelve a a armar otra gorda.
Y si atrasas el reloj ni te cuento.
En algunos casos se pueden colgar las X...
Sí, vale, a los programas sí, eso lo veo normal. Pero que el demonio ntp no pueda sincronizar el reloj del sistema porque tiene un desfase de, por ejemplo, una semana, pues no lo entiendo, para éso precisamente quiero sincronizarlo :-P. Es decir, que los programas se "desbarajusten" debido a los cambios de fecha, entiendo que es problema del administrador, no del demonio ntp ;-). Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2007-12-03 a las 09:24 +0100, Camaleón escribió:
El 3/12/07, Carlos E. R. escribió:
No, el reloj local no se puede desactivar nunca, es el principal. Es el reloj del sistema, que se puede consultar cientos de veces por segundo. Eso no se puede hacer con uno de red.
Quería decir que probaras a comentar (desactivar) en /etc/ntpd.conf el reloj indisciplinado para que el demonio ntp no lo use a la hora de sincronizar. Así le fuerzas a usar sólo la sincronización con servidores de tiempo remotos.
El ntp no usa el reloj del sistema para sincronizar. Eso es como mirarte el reloj de la muñeca para poner en hora el reloj de la muñeca - aunque de hecho eso es lo que hace cuando no tiene reloj en la red para no desactivar el código. Es un truco de programador. No lo puedes cambiar y no serviría de nada aunque se hiciera. Es como sacar la manilla al reloj de pulsera para ponerlo en hora, ponerte a dar vueltas a la manilla, y entonces ver que no tienes otro reloj donde mirar la hora para ponerlo en hora. El problema es que el reloj del sistema se desboca y no obedece los cambios de frecuencia que le manda el ntp. O eso o hace saltos, que es lo que yo pienso, que se para porque pierde impulsos o interrupciones. Yo creo que han cambiado algo en el kernel para usar el reloj de otra forma y va mal en determinadas circunstancias.
No creo que tenerlo activado sea obligatorio ¿no? No es el reloj del sistema, y no todo el mundo tiene instalado un servidor de sincronización de tiempo por lo que no lo veo necesario :-?
El reloj del sistema puede ir independiente, que es lo que hemos hecho toda la vida, o se puede ajustar de vez en cuando con otro externo, que es lo que hace el ntp.
Correcto.
No es cuestión de que tenga sentido o no, ese es el reloj del sistema y no se puede cambiar, es central al kernel. A todo kernel de todo ordenador de toda arquitectura... fíjate si hay cosas hechas en común. Si el reloj del sistema no funciona estamos jo... jorobados, eso.
¿Dices que el reloj idisciplinado es el reloj del sistema? :-? No lo entiendo. A ver, ¿no es posible configurar ntp para que use sólo servidores externos? Que ntp no pueda sincronizar la hora no quiere decir que se desajuste el reloj del sistema, vaya, sencillamente tendrá segundos de desfase, pero nada más...
A ver, a ver. Que no tengo problemas con ntp. Tengo problemas con el reloj del sistema, que se para, o algo así, y es el ntp quien se da cuenta. Esto es un ciclo completo del ntp de una de las veces que me falló el reloj. 27 Nov 15:27:20 ntpd[12539]: offset 0.000000 sec freq 82.712 ppm error 0.000001 poll 6 27 Nov 15:27:38 ntpd[12905]: system event 'event_restart' (0x01) status 'sync_alarm, sync_unspec, 1 event, event_unspec' (0xc010) 27 Nov 15:27:38 ntpd[12905]: peer LOCAL(0) event 'event_reach' (0x84) status 'unreach, conf, 1 event, event_reach' (0x8014) 27 Nov 15:27:38 ntpd[12905]: Deleting interface #2 lo, ::1#123, interface stats: received=0, sent=0, dropped=0, active_time=1 secs 27 Nov 15:27:38 ntpd[12905]: Deleting interface #3 eth0, fe80::240:f4ff:fe2e:b121#123, interface stats: received=0, sent=0, dropped=0, active_time=1 secs 27 Nov 15:27:42 ntpd[12905]: peer 91.121... event 'event_reach' (0x84) status 'unreach, conf, 1 event, event_reach' (0x8014) 27 Nov 15:27:44 ntpd[12905]: peer 195.55... event 'event_reach' (0x84) status 'unreach, conf, 1 event, event_reach' (0x8014) 27 Nov 15:27:45 ntpd[12905]: peer 80.33... event 'event_reach' (0x84) status 'unreach, conf, 1 event, event_reach' (0x8014) 27 Nov 15:27:45 ntpd[12905]: peer 217.155... event 'event_reach' (0x84) status 'unreach, conf, 1 event, event_reach' (0x8014) 27 Nov 15:27:45 ntpd[12905]: peer 84.88... event 'event_reach' (0x84) status 'unreach, conf, 1 event, event_reach' (0x8014) 27 Nov 15:27:46 ntpd[12905]: peer 88.191... event 'event_reach' (0x84) status 'unreach, conf, 1 event, event_reach' (0x8014) 27 Nov 15:27:46 ntpd[12905]: peer 192.33... event 'event_reach' (0x84) status 'unreach, conf, 1 event, event_reach' (0x8014) 27 Nov 15:30:51 ntpd[12905]: system event 'event_peer/strat_chg' (0x04) status 'sync_alarm, sync_local_proto, 2 events, event_restart' (0xc521) 27 Nov 15:30:51 ntpd[12905]: synchronized to LOCAL(0), stratum 10 27 Nov 15:30:51 ntpd[12905]: kernel time sync status change 0001 27 Nov 15:30:51 ntpd[12905]: system event 'event_sync_chg' (0x03) status 'leap_none, sync_local_proto, 3 events, event_peer/strat_chg' (0x534) 27 Nov 15:30:51 ntpd[12905]: system event 'event_peer/strat_chg' (0x04) status 'leap_none, sync_local_proto, 4 events, event_sync_chg' (0x543) 27 Nov 15:31:56 ntpd[12905]: synchronized to 91.121..., stratum 2 27 Nov 15:38:31 ntpd[12905]: synchronized to 192.33..., stratum 2 27 Nov 15:39:25 ntpd[12905]: synchronized to 195.55..., stratum 2 27 Nov 15:39:40 ntpd[12905]: synchronized to LOCAL(0), stratum 10 27 Nov 15:39:40 ntpd[12905]: synchronized to LOCAL(0), stratum 10 27 Nov 16:22:22 ntpd[12905]: synchronized to 84.88..., stratum 2 27 Nov 16:22:22 ntpd[12905]: time correction of 1678 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time. 27 Nov 16:22:22 ntpd[12905]: system event 'event_fault' (0x02) status 'leap_none, sync_ntp, 12 events, event_peer/strat_chg' (0x6c4) 27 Nov 17:13:54 ntpd[18877]: system event 'event_restart' (0x01) status 'sync_alarm, sync_unspec, 1 event, event_unspec' (0xc010) Tú lo que dices es quitar estas lineas: server 127.127.1.0 # local clock (LCL) fudge 127.127.1.0 stratum 10 # LCL is unsynchronized Creo que las necesita, pero probaré.
Claro está que se pueden tocar los margenes y las velocidades en la configuración, pero ese no es el problema de fondo...
Pues sí que le afecta el tiempo a los sistemas... entiendo que haya problemas con los programas que dependen, pero el sistema "per se" no debería verse afectado de igual forma.
Es por el diseño del unix. En unix el reloj del sistema es un contador que se va incrementando continuamente desde que arranca, con la cuenta marcando los segundos desde noseque dia de que año. Cuando quieres saber la hora humana, haces la conversión. La alteración de ese contador es lo que vuelve locos a los programas. En cambio, si el reloj "humano" fuera independiente del contador, no pasaría nada - que es lo que hace el msdos, al que no le afectan los cambios de hora.
Y si atrasas el reloj ni te cuento.
En algunos casos se pueden colgar las X...
Sí, vale, a los programas sí, eso lo veo normal. Pero que el demonio ntp no pueda sincronizar el reloj del sistema porque tiene un desfase de, por ejemplo, una semana, pues no lo entiendo, para éso precisamente quiero sincronizarlo :-P.
Lo que te dice el ntp es que él no puede cambiarte el reloj de forma lenta porque está demasiado lejos. Si quieres, tú como administrador puedes decirle que lo haga a pesar de todo, aunque tarde dias en ajustarlo. Viene en el manual. En ajustar una hora de retraso puede tardar no recuerdo si es un dia. Si tienes esa paciencia... pero es un dia entero en que el reloj va a estar mal, casi una hora de retraso. Primero una hora, luego 59 minutos, luego 58 minutos, luego 57... y a las nosecuantas horas, ya marcará bien. Vas a tener en los registros todos los eventos marcados a una hora falsa durante un día. Si el desfase es de una semana igual tarda un mes o un año en ponerse al día... no recuerdo cual es la variación admisible, eso está documentado pero no tengo el documento cargado ahora.
Es decir, que los programas se "desbarajusten" debido a los cambios de fecha, entiendo que es problema del administrador, no del demonio ntp ;-).
Pero como los desarrolladores del ntp lo saben, dejan esa decisión al administrador. ¡El fallo que tienen es que no hacen sonar las alarmas! - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHU/TPtTMYHG2NR9URAjXrAJ0UXOUmhkvRfzQ0uA8/rbK1f9RZYACePY46 XC4v/DWaehgujlOz/e1u3EA= =DNzj -----END PGP SIGNATURE-----
El 3/12/07, Carlos E. R. escribió:
A ver, a ver.
Que no tengo problemas con ntp. Tengo problemas con el reloj del sistema, que se para, o algo así, y es el ntp quien se da cuenta.
Ah, jupe. ¿Y qué pinta el ntp entonces >:-)? Si no activas el servicio ¿hay bug o no hay bug? ¿mantienes la hora o no mantienes la hora? ¿No tendrás la pila de la cmos de la bios seca?
Esto es un ciclo completo del ntp de una de las veces que me falló el reloj.
27 Nov 15:31:56 ntpd[12905]: synchronized to 91.121..., stratum 2 27 Nov 15:38:31 ntpd[12905]: synchronized to 192.33..., stratum 2 27 Nov 15:39:25 ntpd[12905]: synchronized to 195.55..., stratum 2
Sincroniza con los servidores remotos...
27 Nov 15:39:40 ntpd[12905]: synchronized to LOCAL(0), stratum 10 27 Nov 15:39:40 ntpd[12905]: synchronized to LOCAL(0), stratum 10
...y con el local-indisciplinado :-?
27 Nov 16:22:22 ntpd[12905]: synchronized to 84.88..., stratum 2 27 Nov 16:22:22 ntpd[12905]: time correction of 1678 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time.
Y horas más tarde, dice que el desfase es tremendo y no puede establecer la hora :-?
Tú lo que dices es quitar estas lineas:
server 127.127.1.0 # local clock (LCL) fudge 127.127.1.0 stratum 10 # LCL is unsynchronized
Sasto.
Creo que las necesita, pero probaré.
Eso es lo que comentaba, que no sé para qué las necesita si: - Al iniciar conecta con los servidores remotos - Los servidores remotos están configurados - En caso de error de red (no puede conectar) debería usar la hora del sistema sin necesidad del indisciplinado... hum, quizá lo necesite para eso mismo.
Lo que te dice el ntp es que él no puede cambiarte el reloj de forma lenta porque está demasiado lejos. Si quieres, tú como administrador puedes decirle que lo haga a pesar de todo, aunque tarde dias en ajustarlo. Viene en el manual.
27 minutos de desfase y no lo permite... Bueno, y a todo ésto ¿por qué pierdes la hora? No actives ntpd o configúralo para que sincronice sólo una vez a día >:-) Ahora en serio, lo del ntp salvo que sea necesario para tareas concretas que requieran precisión milimétrica de la hora, pues yo lo dejaría para que sincronizara una vez a la semana, creo que sería suficiente.
Pero como los desarrolladores del ntp lo saben, dejan esa decisión al administrador.
¡El fallo que tienen es que no hacen sonar las alarmas!
Ah, que permitan establecerlo de forma manual me parece bien, entonces sí... y ¿qué más alarmas quieres además que notificarlo en el registro :-)? Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
El 3/12/07, Carlos E. R. escribió:
A ver, a ver.
Que no tengo problemas con ntp. Tengo problemas con el reloj del sistema, que se para, o algo así, y es el ntp quien se da cuenta.
Ah, jupe. ¿Y qué pinta el ntp entonces >:-)?
Pues porque lo tengo puesto desde hace tiempo - bueno, desde que tengo adsl.
Si no activas el servicio ¿hay bug o no hay bug? ¿mantienes la hora o no mantienes la hora? ¿No tendrás la pila de la cmos de la bios seca?
No, no he probado a desactivarlo, pero sospecho que pasaría lo mismo, aunque silenciosamente. Y la pila no tiene nada que ver, aunque es una confusión habitual; el reloj de la cmos sólo se consulta una única vez, durante el arranque.
Esto es un ciclo completo del ntp de una de las veces que me falló el reloj.
27 Nov 15:31:56 ntpd[12905]: synchronized to 91.121..., stratum 2 27 Nov 15:38:31 ntpd[12905]: synchronized to 192.33..., stratum 2 27 Nov 15:39:25 ntpd[12905]: synchronized to 195.55..., stratum 2
Sincroniza con los servidores remotos...
27 Nov 15:39:40 ntpd[12905]: synchronized to LOCAL(0), stratum 10 27 Nov 15:39:40 ntpd[12905]: synchronized to LOCAL(0), stratum 10
...y con el local-indisciplinado :-?
Sip, supongo que perdió el servidor de red, aunque el log del ntp tiene tan pocos detalles que no se sabe el motivo.
27 Nov 16:22:22 ntpd[12905]: synchronized to 84.88..., stratum 2
Y tarda casi una hora en pillar otro.
27 Nov 16:22:22 ntpd[12905]: time correction of 1678 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time.
Y horas más tarde, dice que el desfase es tremendo y no puede establecer la hora :-?
Sí, cuando vuelve a consultar la red.
Tú lo que dices es quitar estas lineas:
server 127.127.1.0 # local clock (LCL) fudge 127.127.1.0 stratum 10 # LCL is unsynchronized
Sasto.
Creo que las necesita, pero probaré.
Eso es lo que comentaba, que no sé para qué las necesita si:
- Al iniciar conecta con los servidores remotos - Los servidores remotos están configurados - En caso de error de red (no puede conectar) debería usar la hora del sistema sin necesidad del indisciplinado... hum, quizá lo necesite para eso mismo.
Creo que es un simple truco para no cambiar el código. Es lo de poner el reloj de la muñeca mirando el reloj de la muñeca.
Lo que te dice el ntp es que él no puede cambiarte el reloj de forma lenta porque está demasiado lejos. Si quieres, tú como administrador puedes decirle que lo haga a pesar de todo, aunque tarde dias en ajustarlo. Viene en el manual.
27 minutos de desfase y no lo permite... Bueno, y a todo ésto ¿por qué pierdes la hora? No actives ntpd o configúralo para que sincronice sólo una vez a día >:-)
Vamos a ver, el reloj siempre ha ido bien. Y el ntp también me ha ido bien siempre. La hora se pierde porque los del kernel han metido la gamba.
Ahora en serio, lo del ntp salvo que sea necesario para tareas concretas que requieran precisión milimétrica de la hora, pues yo lo dejaría para que sincronizara una vez a la semana, creo que sería suficiente.
¿Y que más da? tendría que ir bien. Iba bien.
Pero como los desarrolladores del ntp lo saben, dejan esa decisión al administrador.
¡El fallo que tienen es que no hacen sonar las alarmas!
Ah, que permitan establecerlo de forma manual me parece bien, entonces sí... y ¿qué más alarmas quieres además que notificarlo en el registro :-)?
El ntp sólo notifica en el log que abandona, pero lo hace con prioridad normal, cuando debería ser una alarma que se registre en el /var/log/warn. Si saliera ahí me daría cuenta, y me tengo que dar cuenta cuando miro el reloj del vídeo. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHVApLtTMYHG2NR9URAu/SAJ4jaD55rauD5DOmrznOn2YasF3G/wCfcZrr 0tunjSWni8v79vHAAC/a1vg= =NdJf -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2007-12-03 a las 13:21 +0100, Carlos E. R. escribió:
Lo que te dice el ntp es que él no puede cambiarte el reloj de forma lenta porque está demasiado lejos. Si quieres, tú como administrador puedes decirle que lo haga a pesar de todo, aunque tarde dias en ajustarlo. Viene en el manual.
En ajustar una hora de retraso puede tardar no recuerdo si es un dia. Si tienes esa paciencia... pero es un dia entero en que el reloj va a estar mal, casi una hora de retraso. Primero una hora, luego 59 minutos, luego 58 minutos, luego 57... y a las nosecuantas horas, ya marcará bien. Vas a tener en los registros todos los eventos marcados a una hora falsa durante un día.
Si el desfase es de una semana igual tarda un mes o un año en ponerse al día... no recuerdo cual es la variación admisible, eso está documentado pero no tengo el documento cargado ahora.
Dice el manual (ntpd.html): The maximum slew rate possible is limited to 500 parts-per-million (PPM) as a consequence of the correctness principles on which the NTP protocol and algorithm design are based. As a result, the local clock can take a long time to converge to an acceptable offset, about 2,000 s for each second the clock is outside the acceptable range. During this interval the local clock will not be consistent with any other network clock and the system cannot be used for distributed applications that require correctly synchronized network time. Es decir, un retraso de 1000 segundos tardará en corregirse 2 millones de segundos, esto es, 23 dias (si no me confundo en los calculos, porque parece una barbaridad) y por eso abandona: LOG_ERR time correction of ? seconds exceeds sanity limit (?); set clock manually to the correct UTC time. Fatal error. Better do what it says, then restart the daemon. Be advised NTP and Unix know nothing about local time zones. The clock must be set to Coordinated Universal Time (UTC). Believe it; by international agreement abbreviations are in French and descriptions are in English. sigaction() fails to save SIGSYS trap: ? sigaction() fails to restore SIGSYS trap: ? Program error. Please report to bugs@ntp.org. Lo que puedo hacer es borrar el fichero drift cuando pase. Ahora mismo marca 76.927. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHVAyAtTMYHG2NR9URAvnoAJ9lOjGmg3b784YAIfqBJmJuzcNmJwCeKuEP AnOyotxH+3PvVfO+wt7HqN8= =wIP3 -----END PGP SIGNATURE-----
El 3/12/07, Carlos E. R. escribió:
No, no he probado a desactivarlo, pero sospecho que pasaría lo mismo, aunque silenciosamente. Y la pila no tiene nada que ver, aunque es una confusión habitual; el reloj de la cmos sólo se consulta una única vez, durante el arranque.
Es que es extraño... a ver, pensando en voz alta: - Si desactivas el servicio ntpd y el reloj se desajusta, bug del kernel - Si es un bug del kernel, ¿bajo qué circunstancias se activa? - Si es un bug del kernel, ntpd no puede hacer nada, porque llega un momento en el que el desfase es superior a su configuración permitida para modificar la hora (~25 min.) Revisa si te está mordiendo alguno de estos problemas que están en la página de ntp: http://support.ntp.org/bin/view/Support/KnownOsIssues#Section_9.2.3.2.
Vamos a ver, el reloj siempre ha ido bien.
Y el ntp también me ha ido bien siempre.
La hora se pierde porque los del kernel han metido la gamba.
Ah, vale. Entonces hay que saber a qué tipo de sistemas afecta (¿placas, bios...?) porque no sucede con todos los equipos. Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2007-12-03 a las 15:33 +0100, Camaleón escribió:
El 3/12/07, Carlos E. R. escribió:
No, no he probado a desactivarlo, pero sospecho que pasaría lo mismo, aunque silenciosamente. Y la pila no tiene nada que ver, aunque es una confusión habitual; el reloj de la cmos sólo se consulta una única vez, durante el arranque.
Es que es extraño... a ver, pensando en voz alta:
- Si desactivas el servicio ntpd y el reloj se desajusta, bug del kernel - Si es un bug del kernel, ¿bajo qué circunstancias se activa?
Estoy seguro de ello. Pero no puedo trazarlo porque no hay logs.
- Si es un bug del kernel, ntpd no puede hacer nada, porque llega un momento en el que el desfase es superior a su configuración permitida para modificar la hora (~25 min.)
Exacto.
Revisa si te está mordiendo alguno de estos problemas que están en la página de ntp:
http://support.ntp.org/bin/view/Support/KnownOsIssues#Section_9.2.3.2.
Mmmm... vale, voy a bajarle la frecuencia al reloj del kernel, que la he llegado a tener a 1000 y ahora está a 300. Aunque entre 250 (que es el valor por defecto en suse) y 300 no hay tanta diferencia para que sea un problema... luego no es eso. Mmm... si dice que hay un problema con reiserfs que no deja actuar a la interrupción del reloj en varios ciclos, y yo ahora mismo estoy recompilando el kernel, y eso sucede precisamente en una partición reiser, y además yo estaba comiendo, y el reloj no se ha retrasado... entonces no es eso. Además, los retrasos parecen ocurrir cuando la máquina no está haciendo nada. Podría ser...: 9.2.3.2.8. Kernel 2.6 Mis-Detecting CPU TSC Frequency Starting with Linux Kernel 2.6.18, the CPU's Time Stamp Counter is used to keep time, and when booting sometimes the Kernel mis-detects the frequency of this counter. This may result in severe clock drift which is impossible for ntpd to correct. One solution to this problem is to change back to the old "acpi_pm" clock, which is what was used in earlier kernels. For example, in your grub.conf file, you can set: clocksource=acpi_pm And then reboot. A similar procedure is apparently possible with earlier versions of Kernel 2.6, which uses a "clock=" designation instead of "clocksource=". Our thanks to Jordan Russell for locating and resolving this issue. Y ciertamente, mi kernel arranca con el reloj tsc: cer@nimrodel:/usr/src/linux> grep -i clock /var/log/boot.msg <6>Time: tsc clocksource has been installed. <6>Real Time Clock Driver v1.12ac <6>Time: acpi_pm clocksource has been installed. <6>intel8x0_measure_ac97_clock: measured 50655 usecs <6>intel8x0: clocking to 48000 doneSetting up the hardware clockdone Mmmm... tiene los dos, tsc y acpi_pm. ¿Cual está usando entonces? :-?
Vamos a ver, el reloj siempre ha ido bien.
Y el ntp también me ha ido bien siempre.
La hora se pierde porque los del kernel han metido la gamba.
Ah, vale. Entonces hay que saber a qué tipo de sistemas afecta (¿placas, bios...?) porque no sucede con todos los equipos.
Ni idea. En la 10.2 no tenía problemas, y yo no sigo el desarrollo del kernel, luegono puedo saber que han cambiado. Tengo abierto un bugzilla, y lo único que sacan es que no es el ntp. ¿Que versión de kernel usa la 10.2, lo sabe alguien? - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHVCddtTMYHG2NR9URAhfkAJ9pkNbwiSQWlvuMaIPwHhZ0FnOHgACggJnr AtXMNjivtmD9MX3P/vFf8Ng= =77H9 -----END PGP SIGNATURE-----
El 3/12/07, Carlos E. R. escribió:
Y ciertamente, mi kernel arranca con el reloj tsc:
cer@nimrodel:/usr/src/linux> grep -i clock /var/log/boot.msg <6>Time: tsc clocksource has been installed. <6>Real Time Clock Driver v1.12ac <6>Time: acpi_pm clocksource has been installed. <6>intel8x0_measure_ac97_clock: measured 50655 usecs <6>intel8x0: clocking to 48000 doneSetting up the hardware clockdone
Mmmm... tiene los dos, tsc y acpi_pm. ¿Cual está usando entonces? :-?
"M'has dao" curiosidad O:-) suse 10.0 / 2.6.13-15.18-smp : linux:~ # grep -i clock /var/log/boot.msg <6>Real Time Clock Driver v1.12 Setting up the CMOS clockdone suse 10.1 / 2.6.16.53-0.16-default: stt028:~ # grep -i clock /var/log/boot.msg <6>Real Time Clock Driver v1.12ac <6>intel8x0_measure_ac97_clock: measured 53126 usecs <6>intel8x0: clocking to 48000 Setting up the hardware clockdone suse 10.3 / 2.6.22.12-0.1-default: linux01:~ # grep -i clock /var/log/boot.msg <6>Time: tsc clocksource has been installed. <6>Real Time Clock Driver v1.12ac Setting up the hardware clockdone
¿Que versión de kernel usa la 10.2, lo sabe alguien?
Ni idea :-? Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
El 3/12/07, Carlos E. R. escribió:
Mmmm... tiene los dos, tsc y acpi_pm. ¿Cual está usando entonces? :-?
"M'has dao" curiosidad O:-)
suse 10.0 / 2.6.13-15.18-smp :
linux:~ # grep -i clock /var/log/boot.msg <6>Real Time Clock Driver v1.12 Setting up the CMOS clockdone
suse 10.1 / 2.6.16.53-0.16-default:
stt028:~ # grep -i clock /var/log/boot.msg <6>Real Time Clock Driver v1.12ac <6>intel8x0_measure_ac97_clock: measured 53126 usecs <6>intel8x0: clocking to 48000 Setting up the hardware clockdone
suse 10.3 / 2.6.22.12-0.1-default:
linux01:~ # grep -i clock /var/log/boot.msg <6>Time: tsc clocksource has been installed. <6>Real Time Clock Driver v1.12ac Setting up the hardware clockdone
¿Que versión de kernel usa la 10.2, lo sabe alguien?
Ni idea :-?
Es que el TSC aparece en la 2.6.18, según ese documento de los de ntp. Tendré que mirarlo. [...] http://download.opensuse.org/distribution/10.2/repo/oss/suse/i586/ El 2.6.18.2. Miraré en mi backup... cer@nimrodel:/mnt/usb/usb_sg60/system/var/log> grep -i clock /mnt/usb/usb_sg60/system/var/log/boot.msg <6>Real Time Clock Driver v1.12ac <6>Time: tsc clocksource has been installed. <6>Time: acpi_pm clocksource has been installed. <6>intel8x0_measure_ac97_clock: measured 50928 usecs <6>intel8x0: clocking to 48000 <notice>boot.clock start Setting up the hardware clockdone <notice>'boot.clock start' exits with status 0 Pues es lo mismo, y entonces iba bien... ¿Cómo se cual está usando? - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHVEJStTMYHG2NR9URAiySAJ9VWZq8J5WhxTfgCW7ONrsI6KvUogCfaCgx O1xG0sgbfVjuHL7VbJOgcjk= =xlO8 -----END PGP SIGNATURE-----
2007/12/3, Carlos E. R.:
El 2.6.18.2.
Miraré en mi backup...
cer@nimrodel:/mnt/usb/usb_sg60/system/var/log> grep -i clock /mnt/usb/usb_sg60/system/var/log/boot.msg <6>Real Time Clock Driver v1.12ac <6>Time: tsc clocksource has been installed. <6>Time: acpi_pm clocksource has been installed. <6>intel8x0_measure_ac97_clock: measured 50928 usecs <6>intel8x0: clocking to 48000 <notice>boot.clock start Setting up the hardware clockdone <notice>'boot.clock start' exits with status 0
Pues es lo mismo, y entonces iba bien... ¿Cómo se cual está usando?
Parece que no funciona... A ver, en kerneltrap hay algunos mensajes relacionados (ojo, hablan del kernel 2.6.21.3): http://kerneltrap.org/node/8306 Y en este comentario, dicen que ese parámetro "clocksource=acpi_pm" no funciona: http://kerneltrap.org/node/8306#comment-269324 Más abajo comentan el uso de "notsc" pero no sé qué hace realmente porque si lo desactiva ¿cómo establece la hora? :-/ Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2007-12-03 a las 19:48 +0100, Camaleón escribió:
Pues es lo mismo, y entonces iba bien... ¿Cómo se cual está usando?
Parece que no funciona...
A ver, en kerneltrap hay algunos mensajes relacionados (ojo, hablan del kernel 2.6.21.3):
Sorpresa: nimrodel:~ # cat /sys/devices/system/clocksource/clocksource0/available_clocksource acpi_pm pit jiffies tsc nimrodel:~ # cat /sys/devices/system/clocksource/clocksource0/current_clocksource acpi_pm
Y en este comentario, dicen que ese parámetro "clocksource=acpi_pm" no funciona:
Puede ser simplemente que quien lo reportó no tenga ese tipo de reloj.
Más abajo comentan el uso de "notsc" pero no sé qué hace realmente porque si lo desactiva ¿cómo establece la hora? :-/
No, usaría otro de los sistemas posibles. En /usr/src/linux/Documentation/kernel-parameters.txt dice: clock= [BUGS=IA-32, HW] gettimeofday clocksource override. [Deprecated] Forces specified clocksource (if available) to be used when calculating gettimeofday(). If specified clocksource is not available, it defaults to PIT. Format: { pit | tsc | cyclone | pmtmr } clocksource= [GENERIC_TIME] Override the default clocksource Format: <string> Override the default clocksource and use the clocksource with the name specified. Some clocksource names to choose from, depending on the platform: [all] jiffies (this is the base, fallback clocksource) [ACPI] acpi_pm [ARM] imx_timer1,OSTS,netx_timer,mpu_timer2, pxa_timer,timer3,32k_counter,timer0_1 [AVR32] avr32 [IA-32] pit,hpet,tsc,vmi-timer; scx200_hrt on Geode; cyclone on IBM x440 [MIPS] MIPS [PARISC] cr16 [S390] tod [SH] SuperH [SPARC64] tick [X86-64] hpet,tsc Y lo de 'notsc' está documentado: notsc [BUGS=IA-32] Disable Time Stamp Counter - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHVG8ltTMYHG2NR9URAuEXAJ0fx3fFv6sMyPjuAiGpqMjeOMcNmgCeKd3p qGaP4WOlTBwubBh3TdZyfHc= =99wh -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
El 3/12/07, Carlos E. R. escribió:
Tú lo que dices es quitar estas lineas:
server 127.127.1.0 # local clock (LCL) fudge 127.127.1.0 stratum 10 # LCL is unsynchronized
Sasto.
Creo que las necesita, pero probaré.
Pues probé, y hay diferencias. Cuando pierde la conexión, en vez del mensaje "synchronized to LOCAL(0), stratum 10", sale esto: 3 Dec 19:11:29 ntpd[29084]: synchronized to 88.191.43.2, stratum 2 3 Dec 19:12:44 ntpd[29084]: synchronized to 213.96.197.96, stratum 2 3 Dec 19:13:34 ntpd[29084]: no servers reachable 3 Dec 19:20:14 ntpd[29084]: synchronized to 88.191.43.2, stratum 2 3 Dec 19:21:32 ntpd[29084]: synchronized to 213.96.197.96, stratum 2 3 Dec 19:22:36 ntpd[29084]: synchronized to 88.191.43.2, stratum 2 3 Dec 19:31:42 ntpd[29084]: time reset +309.343782 s En veinte minutos de desconexión, ¡300 segundos de error! Y antes de una hora, vuelve a pasar: 3 Dec 19:31:42 ntpd[29084]: system event 'event_clock_reset' (0x05) status 'sync_alarm, sync_unspec, 15 events, event_peer/strat_chg' (0xc0f4) 3 Dec 19:31:42 ntpd[29084]: system event 'event_peer/strat_chg' (0x04) status 'sync_alarm, sync_unspec, 15 events, event_clock_reset' (0xc0f5) 3 Dec 19:31:44 ntpd[29084]: peer 213.96.200.126 event 'event_reach' (0x84) status 'unreach, conf, 2 events, event_reach' (0x8024) 3 Dec 19:31:45 ntpd[29084]: peer 81.19.16.225 event 'event_reach' (0x84) status 'unreach, conf, 2 events, event_reach' (0x8024) 3 Dec 19:32:23 ntpd[29084]: peer 88.191.43.2 event 'event_reach' (0x84) status 'unreach, conf, 2 events, event_reach' (0x8024) 3 Dec 19:32:24 ntpd[29084]: peer 195.92.137.112 event 'event_reach' (0x84) status 'unreach, conf, 2 events, event_reach' (0x8024) 3 Dec 19:32:30 ntpd[29084]: peer 193.138.215.60 event 'event_reach' (0x84) status 'unreach, conf, 2 events, event_reach' (0x8024) 3 Dec 19:32:34 ntpd[29084]: peer 213.96.197.96 event 'event_reach' (0x84) status 'unreach, conf, 2 events, event_reach' (0x8024) 3 Dec 19:36:40 ntpd[29084]: synchronized to 88.191.43.2, stratum 2 3 Dec 19:36:40 ntpd[29084]: system event 'event_sync_chg' (0x03) status 'leap_none, sync_ntp, 15 events, event_peer/strat_chg' (0x6f4) 3 Dec 19:36:40 ntpd[29084]: system event 'event_peer/strat_chg' (0x04) status 'leap_none, sync_ntp, 15 events, event_sync_chg' (0x6f3) 3 Dec 20:01:13 ntpd[29084]: offset 0.002029 sec freq 79.654 ppm error 0.002737 poll 6 3 Dec 20:15:34 ntpd[29084]: synchronized to 213.96.197.96, stratum 2 3 Dec 20:28:15 ntpd[29084]: no servers reachable 3 Dec 20:30:41 ntpd[29084]: synchronized to 88.191.43.2, stratum 2 3 Dec 20:34:30 ntpd[29084]: time reset +220.290279 s 220 segundos de retraso. Hoy ha vuelto a pasar: 4 Dec 12:00:18 ntpd[5847]: kernel time sync status change 0001 4 Dec 12:00:18 ntpd[5847]: system event 'event_sync_chg' (0x03) status 'leap_none, sync_ntp, 3 events, event_peer/strat_chg' (0x634) 4 Dec 12:00:18 ntpd[5847]: system event 'event_peer/strat_chg' (0x04) status 'leap_none, sync_ntp, 4 events, event_sync_chg' (0x643) 4 Dec 12:04:41 ntpd[5847]: synchronized to 193.39.78.2, stratum 2 4 Dec 12:12:18 ntpd[5847]: synchronized to 212.13.194.71, stratum 2 4 Dec 12:22:58 ntpd[5847]: time reset +0.168114 s Ese es pequeñito. Pero, dos horas más tarde: 4 Dec 12:42:57 ntpd[5847]: synchronized to 212.13.194.71, stratum 2 4 Dec 12:42:59 ntpd[5847]: synchronized to 193.39.78.2, stratum 2 4 Dec 12:45:59 ntpd[5847]: synchronized to 212.13.194.71, stratum 2 4 Dec 12:55:59 ntpd[5847]: offset 0.110640 sec freq -21.718 ppm error 0.005097 poll 6 4 Dec 13:53:34 ntpd[5847]: no servers reachable 4 Dec 13:55:59 ntpd[5847]: offset 0.104618 sec freq 0.315 ppm error 0.003384 poll 6 4 Dec 13:59:02 ntpd[5847]: synchronized to 212.13.194.71, stratum 2 4 Dec 14:04:05 ntpd[5847]: time reset +243.829774 s Hala! 4 Dec 15:09:55 ntpd[5847]: synchronized to 80.59.234.233, stratum 3 4 Dec 15:09:57 ntpd[5847]: no servers reachable 4 Dec 15:17:18 ntpd[5847]: synchronized to 193.39.78.2, stratum 2 4 Dec 15:23:59 ntpd[5847]: time reset +173.514626 s 4 Dec 15:33:19 ntpd[5847]: synchronized to 212.13.194.71, stratum 2 4 Dec 15:52:46 ntpd[5847]: no servers reachable 4 Dec 15:59:14 ntpd[5847]: synchronized to 80.59.234.233, stratum 3 4 Dec 16:02:28 ntpd[5847]: synchronized to 193.39.78.2, stratum 2 4 Dec 16:02:57 ntpd[5847]: offset 0.057789 sec freq 18.518 ppm error 0.006520 poll 6 4 Dec 16:05:21 ntpd[5847]: time reset +4.773942 s Poquito. Buscando en el log por "time reset " veo un montón en un año, con saltos menor del segundo. Pero, justo después de instalar la 10.3, empiezan los saltos: 1 Nov 11:28:02 ntpd[4669]: time reset +0.493571 s 1 Nov 19:54:33 ntpd[6168]: time reset +0.324889 s 2 Nov 11:56:25 ntpd[6168]: time reset +0.493251 s 2 Nov 14:09:49 ntpd[6168]: time reset +0.761453 s 2 Nov 18:57:50 ntpd[6168]: time reset +0.267648 s 2 Nov 19:19:37 ntpd[6168]: time reset +0.633949 s 3 Nov 15:04:26 ntpd[4993]: time reset +13.963114 s <=== upgrade 3 Nov 16:14:24 ntpd[4993]: time reset +126.365828 s 3 Nov 19:12:32 ntpd[5051]: time reset +42.074367 s 4 Nov 12:46:09 ntpd[5076]: time reset +22.996088 s 4 Nov 13:32:56 ntpd[5076]: time reset +393.672856 s 5 Nov 13:35:23 ntpd[5163]: time reset +351.141250 s 5 Nov 14:00:25 ntpd[5163]: time reset +318.950445 s 5 Nov 14:50:51 ntpd[5163]: time reset +0.164107 s 5 Nov 19:55:07 ntpd[5163]: time reset +27.860709 s 5 Nov 23:15:44 ntpd[5163]: time reset +436.175607 s Definitivamente, hay un problema en el kernel o el ntp de la 10.3 - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHVcOKtTMYHG2NR9URAsR+AJ99U24fhYwCxjSsxp3QYC429mkROQCdHR0g aiyo/b/vQ4IiQg46k4a3tiE= =H0Dl -----END PGP SIGNATURE-----
2007/12/4, Carlos E. R.:
4 Dec 12:00:18 ntpd[5847]: kernel time sync status change 0001
Este mensaje de error me ha llamado la atención. En bugzilla de ntp lo achacan a un problema del kernel (comentario 31): https://support.ntp.org/bugs/show_bug.cgi?id=780#c31
Buscando en el log por "time reset " veo un montón en un año, con saltos menor del segundo. Pero, justo después de instalar la 10.3, empiezan los saltos:
1 Nov 11:28:02 ntpd[4669]: time reset +0.493571 s 1 Nov 19:54:33 ntpd[6168]: time reset +0.324889 s 2 Nov 11:56:25 ntpd[6168]: time reset +0.493251 s 2 Nov 14:09:49 ntpd[6168]: time reset +0.761453 s 2 Nov 18:57:50 ntpd[6168]: time reset +0.267648 s 2 Nov 19:19:37 ntpd[6168]: time reset +0.633949 s 3 Nov 15:04:26 ntpd[4993]: time reset +13.963114 s <=== upgrade 3 Nov 16:14:24 ntpd[4993]: time reset +126.365828 s 3 Nov 19:12:32 ntpd[5051]: time reset +42.074367 s 4 Nov 12:46:09 ntpd[5076]: time reset +22.996088 s 4 Nov 13:32:56 ntpd[5076]: time reset +393.672856 s 5 Nov 13:35:23 ntpd[5163]: time reset +351.141250 s 5 Nov 14:00:25 ntpd[5163]: time reset +318.950445 s 5 Nov 14:50:51 ntpd[5163]: time reset +0.164107 s 5 Nov 19:55:07 ntpd[5163]: time reset +27.860709 s 5 Nov 23:15:44 ntpd[5163]: time reset +436.175607 s
Definitivamente, hay un problema en el kernel o el ntp de la 10.3
Vaya desfases... descartar ntp puede ser más sencillo si hay alguna versión reciente que puedas probar en el equipo. Pero yo también apuesto por el kernel, lo que me intriga es el "trigger", qué es lo que lo hace saltar... ¿es tu placa muy "acpi-apic friendly"? ¿te reconoce valores de temperatura, ventilador y demás ("acpi -V" te devuelve algo)? Creo recordar que no tenías ninguna bios nueva a la que actualizar ¿no? Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
2007/12/4, Carlos E. R.:
4 Dec 12:00:18 ntpd[5847]: kernel time sync status change 0001
Este mensaje de error me ha llamado la atención. En bugzilla de ntp lo achacan a un problema del kernel (comentario 31):
Pues mira que hice una busqueda en ese bugzilla y no me encontró nada de nada. Ah, no, espera, que lo que yo he buscado es lo de reset, que es el fallo gordo. Jo, como se las gastan la gente de NTP... dicen que el kernel de linux está roto y que no quieren saber nada de problemas con linux :-/ Y parece que dicen que eso de "kernel time sync status change 0001" es más bien informativo; y no siempre que se ve ese mensaje veo yo lo del reset.
5 Nov 14:50:51 ntpd[5163]: time reset +0.164107 s 5 Nov 19:55:07 ntpd[5163]: time reset +27.860709 s 5 Nov 23:15:44 ntpd[5163]: time reset +436.175607 s
Definitivamente, hay un problema en el kernel o el ntp de la 10.3
Vaya desfases... descartar ntp puede ser más sencillo si hay alguna versión reciente que puedas probar en el equipo.
O la antigua de la 10.2.
Pero yo también apuesto por el kernel, lo que me intriga es el "trigger", qué es lo que lo hace saltar... ¿es tu placa muy "acpi-apic friendly"? ¿te reconoce valores de temperatura, ventilador y demás ("acpi -V" te devuelve algo)?
nimrodel:~ # acpi -V No support for device type: battery No support for device type: thermal No support for device type: ac_adapter Mi placa traga acpi, pero es algo antigua.
Creo recordar que no tenías ninguna bios nueva a la que actualizar ¿no?
Cierto. Pero no puede ser un problema de la bios si siempre ha funcionado hasta ahora. Es la 10.3 la que ha cambiado. Lo que estoy viendo es que esto del ntp es muy poco fiable en realidad, y que la gente que lo desarrolla son muy quisquillosos. A lo mejor nos creemos que el reloj va bien, pero es porque no estamos llevando una comparación frecuente del reloj local con el externo, aparte de la que hace el daemon :-/ Voy a reportrar lo del reset en la inglesa, a ver si salta más gente con problemas. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHVeCntTMYHG2NR9URAsgsAJ44zi95u1+du10b6axAARVK5ibdRACfe35w Aw017xMb4PO40raViksmC/E= =N9uo -----END PGP SIGNATURE-----
El 5/12/07, Carlos E. R. escribió:
Pues mira que hice una busqueda en ese bugzilla y no me encontró nada de nada. Ah, no, espera, que lo que yo he buscado es lo de reset, que es el fallo gordo.
Bueno, el mensaje del "time reset" creo que es posterior ¿no?, indica que ha habido un problema con la sincronización de la hora, pero no te indica el motivo. En cambio, cuando ntpd dice que ha habido un cambio en la sincronización de la hora del kernel (kernel time sync status change) ya te está dando una pista del origen del problema.
Jo, como se las gastan la gente de NTP... dicen que el kernel de linux está roto y que no quieren saber nada de problemas con linux :-/
Y parece que dicen que eso de "kernel time sync status change 0001" es más bien informativo; y no siempre que se ve ese mensaje veo yo lo del reset.
Pues no sé, pero cuanta más información veo por Google, más apunta al kernel: Can a clock drift be too big for ntpd? http://groups.google.com/group/comp.protocols.time.ntp/browse_thread/thread/... ¿Recuerdas la página de ntp donde hablaban de reiser, las interrupciones y la frecuencia? Pues en el hilo de más arriba lo soluciona bajándola a 250, pero podrías probar a bajarla a 100. *** Mensaje del Mié 24 oct 2007 20:06 (...) It works. With kernel HZ reduced to 250 and a Reiser disk mounted, ntp is able to sync. I have gone back to a conventional ntp.conf with multiple servers. ***
O la antigua de la 10.2.
Kernel nuevo (2.6.20) junto con ntp antiguo no es buena combinación porque no estará tan probado. Pero es una opción.
Cierto. Pero no puede ser un problema de la bios si siempre ha funcionado hasta ahora. Es la 10.3 la que ha cambiado.
Que funcionara antes no tiene nada que ver... cosas más extrañas he visto :-). En cuanto modificas un elemento de la composición, los resultados pueden variar de forma considerable. En este caso además, hablamos de un kernel nuevo. Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
participants (2)
-
Camaleón -
Carlos E. R.