dérive excessive de l'horloge système? (2+ minutes par heure)
J'exécute une nouvelle installation de 17.10 sur un nouveau système (entièrement corrigé et non virtualisé) et j'ai constaté que l'heure de démarrage indiquée dans l'entrée btime de /proc/stat ne cessait de changer. Cela cassait certains scripts qui utilisaient ces informations pour calculer l’heure à laquelle certains processus avaient été démarrés.
Avec un peu de débogage, j'ai trouvé que btime est calculé comme suit: now() - uptime, et que la dérive btime est due au fait que l'horloge système a été incrémentée à un taux différent de celui de l'horloge uptime!
J'ai supposé que cela était dû à une sorte de cycle d'horloge appliqué à l'horloge système par systemd-timesyncd.service (c'est-à-dire le remplacement de ntpd). J'ai donc désactivé timesyncd et redémarré, à titre de test. Effectivement, le compteur de temps de disponibilité et le pas de l’horloge système ont la même cadence. (J'ai également installé adjtimex pour vérifier les paramètres du noyau et vérifier qu'il ne reste plus aucun cycle d'horloge: aucun biais frequency n'est appliqué et la valeur tick est comme il se doit.)
Sans timesyncd, cependant, il est clair que l'horloge du système est très instable. L’horloge a perdu environ 5 minutes en 135 minutes (~ -37 000 ppm), ce qui est similaire à ce que j’ai eu avec adjtimex -l -w en 20 minutes environ pour estimer manuellement la dérive de l’horloge système (cela donne ~ -40000 ppm). (Et, en effet, juste pour vérifier, à l’aide d’un chronomètre, j’ai trouvé que /proc/uptime s’incrémentait également au mauvais taux: ~ -41 000 ppm. Donc, cela est cohérent.)
L'horloge CMOS est un peu éteinte aussi (elle a gagné 30 secondes en 135 minutes), mais je crois comprendre que cela ne devrait pas affecter l'horloge système, sauf au moment du démarrage. Je ne peux trouver aucun fichier /etc/adjtime dans lequel la fréquence d'horloge système serait modifiée au démarrage - et de toute façon, comme ci-dessus, adjtimex signale qu'il n'y a pas eu de fudging à l'horloge. Je ne peux donc pas imaginer comment l’horloge CMOS pourrait être à l’origine du problème que je vois avec l’horloge système.
Néanmoins, je vais changer la batterie CMOS, car certains rapports ont suggéré que cela pouvait résoudre miraculeusement les problèmes d'horloge système. (Malgré l'absence de mécanisme évident par lequel cela pourrait se produire.)
Mais y a-t-il une autre explication à la raison pour laquelle l'horloge du système pourrait être si fausse? Et y a-t-il des solutions pour le fait que les minuteries du système sont tellement décalées? Clairement, le fait d'exécuter timesyncd ne résout pas le problème, car l'horloge excessive qu'elle produit est problématique (comme ci-dessus).
Je pourrais utiliser adjtimex pour modifier directement les paramètres du noyau (ce qui devrait au moins synchroniser les compteurs de temps de disponibilité et d'horloge système), mais cela est vraiment destiné à traiter les erreurs d'horloge dans la plage de + - 500 ppm. Ce que je vois est 3 ordres de grandeur plus grand, et je me demande si cela indique un problème plus important.
Pour mémoire, une installation 17.10 que j'ai sur une machine très similaire n'a pas ce problème.
Mise à jour: changer la batterie CMOS n'a rien fait (comme suspecté). Voir ci-dessous pour la résolution finale du problème.
Il s’avère que le problème vient de la source d’horloge TSC. À court terme, changer la source d'horloge en 'hpet' (temporairement via echo hpet > /sys/devices/system/clocksource/clocksource0/current_clocksource, ou de manière plus permanente en ajoutant clocksource=hpet aux paramètres de démarrage du noyau dans /etc/default/grub] résout le problème.
Plus généralement, ce problème est dû à un bogue dans la gestion TSC du noyau Linux concernant les processeurs de bureau Skylake X. Cela devrait être corrigé dans un prochaine version du noya .
Mise à jour: reconstruire le noyau actuel avec le correctif à une ligne du correctif ci-dessus restaure en fait le comportement correct de TSC.