Le Mon, 20 Jul 2015 10:08:07 +0200
François Boisson <[email protected]> a écrit:
> L'heure matérielle est censée se mettre à jour toutes les 11 minutes. En fait
> tout ce passe comme si la machine s'était gelée pendant ces 89,06s. On
> pourrait peut être imaginer que pour une raison ou une autre, aucune
> interruption n'ait été traitée pendant ce laps de temps. Maids ça me parait
> tiré par les cheveux. La machine est un FitPC cadencé à 499.955MHz
Autre chose qui m'incite à penser à des interruptions non traitées:
Voilà un partie du fichier de log (j'"ai une manie, je je fais des logs de
tout):
Dans l'ordre, Jour, Mois, Heure, Minutes, Seconde, Decalage avec
un autre serveur NTP, temps en secondes depuis le début de la journée
et enfin temps écoulé depuis la ligne suivante.
18 Jul 9 32 24 -0,001192 34344 317
18 Jul 9 37 41 -0,001053 34661 325
18 Jul 9 43 6 -0,000326 34986 318
18 Jul 9 48 24 89,060533 35304 314
18 Jul 9 53 38 89,06075 35618 314
18 Jul 9 58 52 89,060771 35932 318
18 Jul 10 4 10 89,061083 36250 314
18 Jul 10 9 24 89,060588 36564 315
18 Jul 10 14 39 89,060753 36879 403
18 Jul 10 21 22 -0,000297 37282 314
18 Jul 10 26 36 -0,000587 37596 314
On voit bien le souci à 09:48:24, on voit bien que malgré le décalage
de leur système, le temps écoulé entre deux enregistrements restde de l'ordre
de 325s. On voit également que lorsque j'ai remis la machine à l'heure,
il y a un décalage de l'ordre de 89s (403 - 89 = 314). Le script est un
while /bin/true; do
betises diverses
sleep 300
done
sleep appelle xnanosleep qui appelle nanosleep. La norme POSIX indique que
«Configurer la valeur de l'horloge CLOCK_REALTIME avec clock_settime() ne
doit pas avoir d'effet sur les threads bloqués attendant un service de temps
relatif basé sur cette horloge. Cela inclut la fonction nanosleep() ;
En conséquence, ces services de temps doivent expirer lorsque la durée
relative demandée est atteinte, indépendamment de l'ancienne ou
la nouvelle valeur de l'horloge. »
En clair donc, il y eu pour la machine 314s d'interruption horloge entre chaque
ligne, changement d'heure ou pas. Lorsque j'ai changé d'heure, lui faisant
rattraper
les 89,06s perdus, on retrouve ces 89,06s dans l'expression du temps écoulé
entre deux
mesures (314s vraies + 89s de décalage du à ma remise à l'heure). Par contre,
lors
du bug, il n'y a pas de décalage dans le temps écoulé, on aurait du avoir
314-89=225 [À ce stade, je félicite les 5 qui sont encore en train de lire!].
Bref
tout ça pour dire qu'on dirait bien que la machine s'est figée 89s ou que c'est
tout comme. Vraiment mystérieux ce truc.
François Boisson
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers [email protected]
En cas de soucis, contactez EN ANGLAIS [email protected]
Archive:
https://lists.debian.org/[email protected]
