Nuits de Chine, nuits câlines

J'ai deux serveurs de temps, l'un synchronisé sur un ensemble de serveurs publics, l'autre synchronisé sur une base temps issue du GPS. Ces deux machines devraient être à la même heure, grâce aux miracles du protocole NTP. Sauf qu'il y a une poignée de secondes^[1] de différence entre eux. C'est le serveur basé sur le GPS qui est considéré comme mal réglé par les outils.

Surprenant. Je plonge dans ma configuration, aidé de ntpmon (surveillance du fonctionnement du service de temps) et cgps (informations reçues du GPS). Tout semble fonctionner, hormis que cgps souligne un décalage de 5 à 7 secondes de la base temps. L'outil indique aussi que mon récepteur « voit » une vingtaine de satellites, et reçoit correctement les données d'une quinzaine d'entre eux. Ça ne semble pas être un problème de manque de données.

Je me tourne donc vers la communauté, plus précisément celle qui sous-tend l'outil gpsd^[2]. Après quelques échanges sur le matériel utilisé, la configuration des outils... rien de bien précis n'apparaît pour expliquer le problème et le résoudre.

Jusqu'à un message disant en substance « désactivez la réception Glonass, leur base temps bat la campagne ».

Dont acte, je configure mon récepteur pour qu'il ignore les satellites Glonass et, en passant, Beidou et Sbas^[3]. Tant qu'à y être, j'active l'utilisation des satellites Galiléo, nous sommes en Europe que diable. Au cas où, si vous utilisez une puce Ublox, la commande est^[4] :

/usr/bin/ubxtool -e GPS -e GA -e NMEA -e PPS -d GLONASS -d BEIDOU -d SBAS

Après quelques minutes, cgps indique que le décalage temporel est revenu dans des valeurs normales (de l'ordre de la demi-seconde). Ntpsec traite la base temps issue du GPS comme une base valide et l'utilise pour l'horloge du serveur de temps. Et mes machines finissent, après quelques heures, par utiliser mon serveur de strate 1 comme référence temporelle. Tout est revenu dans l'ordre.

Moralité : nos amis russes aiment réécrire l'histoire - et le temps, apparemment.