Bonsoir, Et en te fiant à ta première impression du souci matériel, ne serait-ce pas une interférence horloge rtc >> pile du bios ?
Cordialement, Christophe De Natale > Le 20 juil. 2015 à 22:10, François Boisson > <user.anti-s...@maison.homelinux.net> a écrit : > > Le Mon, 20 Jul 2015 10:08:07 +0200 > François Boisson <user.anti-s...@maison.homelinux.net> 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 debian-user-french-requ...@lists.debian.org > En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org > Archive: > https://lists.debian.org/20150720221052.ed978c6fcef37ea27d78f...@maison.homelinux.net > -- 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 debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/f99f5a31-8af0-48d8-a7af-7e08c3473...@orange.fr
