Re: Bug étrange NTP
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-spam@maison.homelinux.net> a écrit :
>
> Le Mon, 20 Jul 2015 10:08:07 +0200
> François Boisson <user.anti-spam@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-REQUEST@lists.debian.org
> En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
> Archive: [🔎] 20150720221052.ed978c6fcef37ea27d78f42a@maison.homelinux.net">https://lists.debian.org/[🔎] 20150720221052.ed978c6fcef37ea27d78f42a@maison.homelinux.net
>
Reply to: