Synchronisation d’ordinateurs par réseau informatique pour la datation sous GNU/Linux : NTP, PTP et GPS sur Raspberry Pi Compute Module 4

1. Introduction

Le transfert de temps est un enjeu dans nombre d’applications technologiques : même si une société moderne ne saurait survivre sans se mettre d’accord sur l’heure (« je suis en retard à mon rendez-vous »), les contraintes sont réduites – un étudiant ne se considère pas en retard jusqu’à 15 minutes après le début du cours – par rapport aux enjeux technologiques de la datation des transactions boursières (qui a obtenu le titre boursier en premier ? Fig. 1), de la production distribuée d’énergie (les pertes en injectant un signal alternatif sur un réseau électrique sont en sin(ϕ) avec ϕ=2π f τ la phase du signal injecté donc son retard τ à fréquence f), de la synchronisation des réseaux de communications téléphoniques ou informatiques [1, 2] notamment pour leur sécurité quand une clé cryptographique doit devenir obsolète avant de pouvoir être dupliquée, à la localisation ou la synthèse de diagramme de rayonnement d’antennes distribuées. Rappelons par exemple qu’aux 143,05 MHz du RADAR GRAVES, la période du signal est 7 ns donc tout retard aléatoire de plus de 60 ps se traduit par un déphasage aléatoire de plus de 3°, avec un impact du retard sur le déphasage d’autant plus important que la fréquence est élevée. Formellement, P. Boven rappelle comment les fluctuations des oscillateurs locaux cadençant des récepteurs de radiotélescopes agencés en réseaux d’antennes dégradent leur capacité de corrélation et donc d’extraction du signal du bruit [3]. Nous viserons donc à asservir le temps entre deux ordinateurs distants de plus de 300 m à mieux que la microseconde pour les transactions boursières [4] ou la nanoseconde pour les applications de RADAR distribué.

Nombre de protocoles de synchronisation existent : NTP (Network Time Protocol décrit dans RFC5905 à https://datatracker.ietf.org/doc/html/rfc5905), PTP (Precise Time Protocol décrit dans RFC8173 à https://datatracker.ietf.org/doc/html/rfc8173), White Rabbit (https://ohwr.org/project/white-rabbit/wikis/home), ou signaux satellitaires de navigation qui sont avant tout du transfert de temps pour permettre la trilatération du récepteur et la correction de son horloge locale au temps commun de la constellation de satellites. Nous allons expliciter lors de leur mise en œuvre ces techniques de synchronisation de résolution croissante, mais aussi de complexité croissante. Cette discussion n’aurait aucun intérêt si elle se limitait aux propriétaires d’horloges atomiques ou de masers à hydrogène, sources de fréquences ultra-stables inaccessibles au commun des mortels. En particulier, alors que PTP nécessite des interfaces Ethernet physiques dédiées capables d’horodater les paquets échangés, il s’avère que la Raspberry Pi Compute Module 4 (CM4), et non pas la Raspberry Pi 4, est équipée des périphériques matériels nécessaires à sa mise en œuvre tel qu’expliqué dans [5] : nous décrirons donc comment asservir une CM4 sur un signal issu de récepteurs GPS.

Tous ces concepts sont strictement inutiles si je ne peux les utiliser en pratique sur mon système d’exploitation favori : les signaux électriques d’une impulsion par seconde (1-PPS) et l’oscillation à 10 MHz sont inexploitables lorsque je tape la commande echo toto > fichier et que je veux savoir la date de sauvegarde du fichier. Que sont ces protocoles et quels sont leurs impacts sur un système informatique distribué en termes de synchronisation ? Comment garantir quel est le fichier le plus récent lorsque de multiples copies sont disponibles ?

La compatibilité de CM4 avec PTP rend donc cette discussion accessible à tout amateur, et change le scénario d’utilisation par son accessibilité et sa simplicité. Voyons donc comment qualifier les latences du système de gestion de fichiers par le noyau Linux et son asservissement sur une source de temps externe.

2. NTP : asservissement logiciel par échange de temps

Le transfert de fréquence est un problème trivial : une onde continue dont toutes les périodes sont aussi similaires que possible à leurs voisines est transmise, et le récepteur compare sa copie locale de l’oscillateur avec ce signal reçu, par exemple au travers d’un mélangeur – un composant qui multiplie deux signaux nommés oscillateur local LO et signal radiofréquence RF pour fournir :

ARFcos(ωRFt) · ALOcos(ωLOt) ∝ ARFALOcos((ωRF−ωLO)t)

après un filtre passe-bas pour éliminer la somme des composantes spectrales – et cherche à annuler cette différence sous hypothèse que les amplitudes ARF et ALO sont constantes, quitte à saturer un comparateur pour s’en assurer. Cette opération s’appelle la syntonisation, c.-⁠à-⁠d. ajuster une fréquence par rapport à une autre. Nous verrons que technologiquement, cette opération n’est pas si simple, car nombre de systèmes numériques sont cadencés avec un oscillateur de fréquence fixe et le contrôle de cet oscillateur par ledit système informatique n’est pas possible, sauf au travers du réglage grossier qu’est /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor pour décider si le processeur réduit sa cadence pour baisser la consommation ou augmente sa cadence pour traiter plus d’informations. Un écart de fréquence entre les oscillateurs cadençant deux ordinateurs distants, inévitable compte tenu de la technologie des oscillateurs contraints par un résonateur piézoélectrique soumis aux aléas géométriques, de température ou de vieillissement, se traduit rapidement par une dérive du temps : un écart de 1 ppm entre deux oscillateurs (donc une fréquence relative de 10⁻⁶ qui est aussi l’écart relatif de temps puisque f=1/t⇒ df/f=−dt/t) se traduit au bout de 5 secondes par un écart de 5 µs ou au bout d’une journée de 260 ms. Cela peut sembler faible, mais 3 secondes au bout d’une semaine commencent à être visibles.

Le transfert de temps est bien plus complexe et donc intéressant : une onde électromagnétique se propage dans une ligne de transmission ou une fibre optique à environ 66 % de sa vitesse dans le vide ou v=200 m/µs. Ainsi, se synchroniser à Besançon sur l’émetteur des horloges atomiques de Mainflingen qui cadencent DCF77 à environ 400 km induit immédiatement un retard de 400· 10³/v≃ 2000 µs ou quelques millisecondes, le délai ionosphérique étant un cas intermédiaire entre le guide d’onde et la propagation en espace libre (v=300 µm/s). Afin d’atteindre une synchronisation submicroseconde pour deux interlocuteurs distants de plus de quelques centaines de mètres, la seule solution est de jouer au ping-pong, en se relançant des messages dont la date d’émission et réception est connue dans le référentiel de chaque horloge des deux interlocuteurs, et sous hypothèse de symétrie du canal de communication (le temps de communication de l’interlocuteur 1 vers 2 est le même que de 2 vers 1), le double temps de vol est mesuré et donc retranché des mesures. Aligner ainsi le temps des interlocuteurs s’appelle la synchronisation, et sa mise en œuvre par un protocole de ping-pong s’appelle le two-way puisqu’il impose que les deux interlocuteurs soient à la fois émetteurs et récepteurs [6].

L’implémentation la plus simple de ces concepts est NTP, dans laquelle toutes ces opérations de synchronisation sont effectuées au niveau logiciel. Comme peu d’ordinateurs généralistes sont capables d’ajuster finement leur fréquence de cadencement, il n’y a pas de syntonisation, juste l’observation et la correction du retard entre les deux interlocuteurs, retard qui ne saurait jamais s’annuler si les oscillateurs cadençant les processeurs ne sont pas exactement à la même fréquence. Même si ces ordinateurs étaient cadencés par d’excellentes horloges atomiques, il suffirait qu’ils soient à des altitudes différentes pour que leur temps local dérive selon les lois enseignées par Einstein. Le problème est désespéré sans un protocole de synchronisation.

Cette compréhension de NTP a deux implications :

1. Les performances en termes de synchronisation sont dépendantes de la stabilité des latences du réseau informatique propageant les messages, et en particulier sa symétrie – par exemple une liaison tantôt terrestre, tantôt satellitaire ne sera pas du tout appropriée.
2. Entre deux corrections, l’oscillateur local est libre et dérive.

Afin de vérifier ces affirmations, nous avons assemblé l’expérience suivante qui sera reprise par la suite pour qualifier tous les mécanismes de synchronisation envisagés : un serveur de temps et fréquence supposé parfait (voir plus loin « White Rabbit » en section 4) cadence un récepteur de radio logicielle Ettus Research X310 muni d’une interface BasicRX qui se contente de transmettre le signal d’entrée sur les convertisseurs analogiques-numériques configurés pour échantillonner à 5 Méchantillons/s (en réalité, les convertisseurs échantillonnent à 200 Méchantillons/s et déciment le flux, sans importance ici), soit une résolution temporelle de 200 ns. Nous connectons la référence de temps issue de White Rabbit (1-PPS) sur l’entrée du récepteur X310 que nous configurons pour se cadencer sur 10 MHz et 1-PPS externe. La X310 est configurée en Time Source: External et Frequency Source: External avec une date de départ dans le futur, par exemple Start Time: 0.2 s afin de démarrer l’acquisition sur le prochain front montant du PPS issu du switch White Rabbit. Une CM4 déclenche la mesure en lançant le script Python d’acquisition qui ne commence effectivement que sur le prochain PPS, acquiert quelques secondes au rythme d’une mesure toutes les 200 ns par définition de la fréquence d’échantillonnage, et stocke le fichier résultant. À la fin de l’acquisition, nous demandons au système d’exploitation GNU/Linux la date de stockage du fichier par stat -c %y. Par ailleurs, le flux de données IQ acquis par le convertisseur analogique-numérique doit permettre de dater le PPS et donc de vérifier que le déclenchement de la mesure a été initié par un tel signal.

La synchronisation par NTP nécessite de compiler le paquet ntp de Buildroot en plus du système d’exploitation GNU/Linux sélectionné par make raspberrypicm4io_64_defconfig, et le daemon est lancé par /etc/init.d/S49ntp* au démarrage du système. Sous réserve que le routage des paquets vers le serveur NTP fonctionne, nous devrions voir dans /tmp/messages apparaître :

indiquant que la synchronisation a eu lieu avec le passage de la date de 1970 à 2023. Par ailleurs, ntpq -p confirme l’adresse du serveur et son statut dont le poll qui indique tous les combien de secondes NTP met à jour l’horloge, intervalle qui croît de 64 à 1024 lorsque la stabilité augmente afin de réduire le volume de transactions sur le réseau.

La séquence de tests décrite ci-dessus s’appuie sur la chaîne de traitement Python produite par GNU Radio Companion et exécutée sur CM4 pour laquelle le support GNU Radio, Python3 et UHD ont été ajoutés dans Buildroot. Enfin, le script suivant :

configure l’interface Ethernet pour optimiser les échanges avec la X310, passe le processeur en mode performance à 1,5 GHz pour limiter les risques de pertes de paquets, et boucle sur une requête de 3 secondes de mesures par la X310 au rythme de 5 MS/s, la sauvegarde de l’horodatage du fichier créé lors de l’acquisition (Fig. 2), et l’analyse du fichier pour identifier la position des fronts montants de l’impulsion produite une fois par seconde 1-PPS et alimentant l’entrée de la X310. Le traitement traite.py se réduit à un simple seuillage :

qui tient en quelques lignes de Python et permet à la mesure de se répéter toutes les 15,7 secondes qui définit la graduation selon l’axe des abscisses de toutes les courbes qui vont suivre.

Lors de la première mesure de ce type, le graphique de la Fig. 4 est produit et fournit bien des enseignements. Les 3600 points de mesure ont nécessité 15h45 de mesures au cours d’une journée. Des fluctuations de l’ordre de ± 10 ms sont observables avec la partie fractionnaire de la date de sauvegarde des fichiers – pour s’affranchir des multiples de la seconde au cours de l’avancement du temps lors de l’évolution de l’expérience – allant de 0,480 à 0,50 s. Cette courbe n’est pas continue, mais elle-même formée d’un motif en dents de scie (insert en bas à droite) dont l’excursion est de 3 ms. Ce motif a déjà été observé par le passé dans d’autres études portant sur la gestion du temps par des noyaux Unix autres que Linux, en particulier à https://frenchfries.net/paul/dfly/nanosleep.html qui date tout de même de 2004, sans que nous puissions identifier de référence plus récente.

L’analyse de cette courbe, qui sera confortée dans la suite par les mesures additionnelles, est la suivante :

• les fluctuations de temps au cours de la journée sont liées à la capacité de correction de NTP, pourtant reliée à un ordinateur local proche de l’observatoire de Besançon qui sert de serveur primaire ;
• la pente des dents de scie est déterminée par l’écart de fréquence entre l’oscillateur local qui cadence le processeur et sa valeur nominale de 54 MHz ;
• l’excursion du motif en dents de scie est déterminée par la granularité du compteur qui cadence le noyau Linux, paramètre configurable à la compilation et qui a été sélectionné au cours de cette expérience à 300 Hz, ou un pas de temps de 3 ms.

Ce motif en dents de scie rappelle immédiatement celui de la sortie 1-PPS des récepteurs GPS Motorola décrit à [8] lié à la fréquence de l’oscillateur utilisé pour produire l’impulsion. Dans ce cas, un comparateur déclenche le PPS sur la transition de la sinusoïde de l’oscillateur local, qui ne peut fournir une résolution temporelle meilleure que sa période. Comme l’oscillateur dérive par rapport à la fréquence nominale des horloges GPS, le PPS se décale lentement jusqu’à avoir sauté à la période suivante, et l’introduction d’un retard permet de recaler le PPS sur la bonne période du signal avant de le laisser dériver à nouveau. Sous réserve que cette dérive soit déterministe par un écart constant entre l’oscillateur local et la fréquence du GPS, l’erreur du motif en dents de scie peut être prédite et l’utilisateur en être informé, à défaut que le matériel n’ait les ressources pour corriger physiquement l’erreur. De la même façon ici, le noyau Linux avec sa granularité grossière voit le temps dériver, mais ne peut rien y faire tant qu’une période n’a pas été dépassée, délai après lequel le compteur peut sauter un cran pour s’aligner à nouveau sur le temps NTP. Cette procédure est caractéristique de synchronisation (ajout de retard) en l’absence de syntonisation (écart de fréquence) quand le matériel ne permet pas d’ajuster la fréquence de l’oscillateur cadençant le processeur tel que c’est le cas sur la CM4 avec son oscillateur fixe.

Compte tenu des implications de sécurité de l’échange de temps entre services informatiques [9], on peut s’interroger de la nature des informations transmises. Une observation par Wireshark informe que le client (gauche) et le serveur (droite) communiquent des informations encapsulées dans des paquets UDP (port 123) de la forme :

Nous ne sommes malheureusement pas en 2093, mais seulement en 2023, et comme préconisé dans [10] le champ Transmit Timestamp du client est rendu aléatoire pour rendre un peu plus difficile l’injection de paquets erronés, mais la manipulation de données erronées notamment en retardant la réponse par une attaque de type Man in the middle y est largement décrite et référencée.

3. PTP : asservissement matériel par échange de temps

L’implémentation logicielle du jeu de ping-pong, affectée par les délais matériels et de traitement logiciel, induit donc des fluctuations de quelques millisecondes à court terme à cause de la synchronisation de l’horloge grossière du système sur l’horloge NTP (dents de scie) et présente des fluctuations long terme de quelques millisecondes.

Afin d’éliminer les fluctuations logicielles, une implémentation matérielle de ce protocole se charge de dater les paquets au niveau de l’interface physique Ethernet au lieu d’effectuer cette opération lors de l’émission des trames. Le retard logiciel est donc éliminé et seul le retard matériel subsiste. Cependant, les interfaces physiques PTP sont munies d’oscillateurs à fréquence fixe (TCXO – Temperature Compensated Crystal Oscillator) et seul le retard peut être corrigé, pas la fréquence. Même si cette fonctionnalité n’est pas disponible sur toute interface Ethernet, il se trouve que la CM4 est munie d’une telle interface (mais pas la Raspberry Pi 4) et peut donc s’asservir sur PTP au lieu de NTP, tel qu’en atteste la commande ethtool -T eth0 qui indique :

Il s’avère par ailleurs que le switch White Rabbit que nous utilisons pour ces expériences propage, depuis sa mise à jour avec la version 6 de son firmware, des trames PTP, donc nous pouvons tester les performances (Fig. 5).

Cette figure illustre l’utilité de la synchronisation, avec dans un premier temps une dérive lorsque l’horloge système reste libre bien que l’interface physique soit asservie sur PTP, avant de lancer le daemon chargé de transmettre le temps PTP au temps système nommé phc2sys. Nous voyons l’impact à la mesure 300 avec le rattrapage du retard accumulé et une compensation périodique de la dérive pour nous recaler sur le temps transmis par PTP, toujours limité par la granularité du compteur qui cadence le noyau. Ainsi, nous retrouvons les motifs en dents de scie que nous avions observés avec NTP, mais avons cette fois éliminé les fluctuations long terme avec une courbe fluctuant peu au cours du temps autour du motif en dents de scie. Le bon fonctionnement de PTP se valide en sondant le statut de l’interface physique par la commande PTP Management Client pmc qui prend en argument la nature des informations requises, en limitant aux interfaces locales seules (-b 0), de la forme :

tandis que le transfert de temps de l’interface physique vers le temps système par phc2sys est validé lorsque date ne fournit plus le premier janvier 1970, mais la date actuelle fournie par le Grandmaster PTP supposé être à l’heure (par NTP ou PTP, par exemple). Nous avons constaté que nous devions relancer le daemon phc2sys par /etc/init.d/S66phc2sys restart une fois l’asservissement PTP par ptp4l fonctionnel pour effectivement engager le transfert de temps de PTP vers le système. Nous prendrons soin par ailleurs de désactiver NTP pour ne pas utiliser par erreur le mauvais mode de synchronisation, tout cela étant automatisé au lancement de la CM4 par :

où les arguments de ptp4l indiquent que nous sommes esclaves (-s pour SlaveOnly), en affichant le statut sur la sortie standard (-m) et en nous appuyant sur la couche Ethernet (-2) au lieu de la couche IP. Par ailleurs, le programme testptp disponible dans les sources du noyau Linux dans tools/testing/selftests/ptp (dans Buildroot dans les sources du noyau qui se trouvent dans output/build/linux-custom) fournit bien des fonctionnalités, par exemple ici la production d’un signal 1-PPS visualisable sur oscilloscope sur la broche 9 de J2 de la Compute Module 4 IO Board [5] placée en sortie. Nous verrons plus tard que cette même broche en entrée permettra de s’asservir sur le signal de cadencement issu d’un récepteur GPS.

Nous constatons donc que PTP permet un asservissement fin de l’horloge système qui sert à dater les fichiers, mais qu’un motif en dents de scie subsiste. Sachant que ce motif en dents de scie est habituellement associé à un compteur de granularité médiocre, nous étudions quel est l’impact de la fréquence du timer du noyau puisque les fluctuations long terme ont disparu, et seul le motif en dents de scie subsiste, d’amplitude 4 ms... qui est justement l’inverse de la configuration du timer dans le noyau Linux, tel que nous le vérifions par exemple sous Debian/GNU Linux par :

qui indique que par défaut, le noyau est cadencé au rythme de 250 observations par seconde. L’aide du noyau Linux sur ces paramètres indique que le choix de ce cadencement est un compromis entre le nombre d’interruptions gérées par le système égal au nombre de cœurs de processeur multiplié par cette fréquence, et que pour un système répondant rapidement aux sollicitations d’un utilisateur, il est judicieux de régler à CONFIG_HZ_1000... alors que Debian maintient la valeur par défaut de 250 Hz.

En étudiant dans Buildroot les options du noyau Linux par make linux-menuconfig, nous constatons que le timer peut prendre des valeurs de 100, 250, 300 et 1000 Hz. Une fois la nouvelle fréquence sélectionnée, make linux recompile le noyau et make place output/images/Image de l’hôte que nous pourrons copier dans la première partition de la carte SD de la cible pour rebooter sur le nouveau noyau. Nous observons les résultats en Fig. 6 : les dents de scie s’atténuent avec une fréquence croissante du timer du noyau, mais il semblerait que de temps en temps le noyau oublie sa mise à jour et laisse l’horloge dériver excessivement. Cet effet est peut-être induit par la puissance de calcul modeste de la CM4, pourtant configurée en gouverneur « performance » pour forcer les 4 cœurs de calcul à 1,5 GHz.

4. White Rabbit : asservissement matériel par échange de temps et fréquence

Nous avons explicité les limitations de synchronisation des interlocuteurs par l’action exclusivement sur le retard en laissant les oscillateurs des interlocuteurs libres de dériver. Ce problème est résolu par l’extension de PTP développée par le CERN nommée White Rabbit qui implémente une solution haute performance en permettant la correction de l’horloge locale cadençant la base de temps. Ce faisant, l’oscillateur contrôlé en tension (VCO) peut se caler sur son maître et ainsi annuler sa dérive. Les performances sont drastiquement améliorées, avec des fluctuations sur la sortie 1-PPS de White Rabbit fluctuant de quelques dizaines de picosecondes contre quelques nanosecondes pour PTP tel que nous l’avons démontré à https://forums.ohwr.org/t/synchronizing-wr-master-and-a-non-wr-node-using-ptp/848417/31. Visuellement, cela se traduit sur un oscilloscope par des fronts d’impulsions de synchronisation qui ne varient non plus de quelques dizaines de nanosecondes, mais seulement de quelques dizaines de picosecondes, à peine perceptible sur une échelle de temps commune (Fig. 7).

Malheureusement, White Rabbit n’est pas accessible au commun des mortels : un switch White Rabbit coûte 2780 euros et les cartes PCI qui transmettent le temps au noyau Linux ont bien du mal à être maintenues fonctionnelles avec les noyaux actuels [11]. Le CERN publiant tous les codes, il est envisageable de porter White Rabbit à tout FPGA muni d’une interface optique (SFP), condition nécessaire à garantir la maîtrise des délais, mais la multiplicité des dépôts interdépendants, la multiplicité des branches incompatibles au sein de chaque dépôt, et la multiplicité des couches d’abstraction (gateware, softcore, modules noyau Linux, applicatifs) rend la tâche ardue sans un lien étroit avec les développeurs White Rabbit, dont la tâche première est de cadencer un accélérateur de particules.

4.1 Analyse de l’impact des fréquences d’oscillateurs sur les performances de datation

Ayant commencé cette étude sur la CM4, nous pouvons tenter d’ajouter la syntonisation – asservissement de la fréquence – à la synchronisation déjà fournie par PTP. L’étude du circuit imprimé indique que seuls deux oscillateurs sont présents, et leur emplacement laisse présager un usage facile à identifier avec un résonateur 25 MHz placé à proximité de l’interface Ethernet de référence BCM5421 et un résonateur 54 MHz placé proche du processeur BCM5711 (Fig. 8). Il sera donc aisé d’analyser l’impact de chaque oscillateur formé du résonateur assemblé en montage Pierce [12, section 2.1] autour d’une porte inverseuse dans le circuit numérique et les deux condensateurs de pieds de quelques pF pour respecter la condition de phase de Barkhausen, voire de le modifier pour permettre l’ajustement dynamique de la fréquence. Cependant, avant d’attaquer les modifications du circuit, nous désirons nous convaincre de la pertinence de la démarche.

Nous commençons ainsi dans un premier temps par une expérience de laboratoire consistant à remplacer les deux résonateurs – 25 et 54 MHz – par deux synthétiseurs programmables émettant une puissance de +4 dBm à leurs fréquences respectives (Fig. 9, droite). Nous constatons dans ce cas que l’observation par un compteur de fréquence (HP53131A) remplace la fréquence naturelle de l’oscillateur (gauche), trop basse, par la fréquence forcée.

Dans ces conditions, nous observons que la source qui cadence l’interface Ethernet n’a aucun impact sur le résultat – tel que nous pouvons nous y attendre avec l’échange d’informations de dates dans les trames PTP – mais que la dérive de l’horloge système peut être ajustée pour changer de direction selon que nous imposions une fréquence supérieure ou inférieure à 54 MHz (Fig. 10, gauche), voire que cette dérive s’annule lorsque nous imposons exactement 54 MHz (Fig. 10, droite).

Dans cette dernière configuration, nous observons un écart type sur la date de sauvegarde des fichiers acquis de la X310 – après avoir éliminé les points évidemment erronés – de l’ordre de 3 µs que nous attribuons aux fluctuations de temps d’exécution des appels système par le noyau multitâche. Le gain est donc de l’ordre de 1000 par rapport à un timer noyau configuré pour être cadencé à 300 Hz (dents de scie de 3 ms d’amplitude). La syntonisation, puisqu’il s’agit ici de l’effet atteint, présente donc un gain significatif que nous désirons automatiser.

La liste de diffusion linuxptp informe par ailleurs d’une option qui pourrait dégrader la vitesse de réponse du noyau à https://linuxptp-users.narkive.com/479lcYvn/status-file-of-achieved-time-synchronization en mentionnant que « you should know that the Linux kernel option CONFIG_NO_HZ_IDLE is harmful to your use case. I recommend to either disable this at compile time or to add "nohz=off" to your kernel command line. Only by using the nohz=off option in the kernel command line, the delay in phc2sys dropped from several microseconds to a hundred nanoseconds. » et en effet, l’option CONFIG_NO_HZ_IDLE est active par défaut, mais l’ajout de nohz=off aux arguments de démarrage du noyau n’a pas modifié le comportement observé.

Cette dernière courbe, Fig. 10 (droite), nous convainc donc de la nécessité de corriger la fréquence de l’oscillateur qui cadence le processeur afin d’éliminer le motif en dents de scie de l’asservissement en temps de l’horloge produite par le noyau exécuté sur le processeur. Nous allons donc aborder le problème du tirage en fréquence de l’oscillateur en nous efforçant d’introduire le moins de composants externes possible, tout en fournissant assez de degrés de liberté pour corriger les fluctuations de fréquences induites par les variations environnementales du résonateur, et en premier lieu sa température.

4.2 Mise en pratique : correction de la fréquence d’un oscillateur à quartz

Il existe de nombreuses façons de corriger la fréquence d’un oscillateur à quartz, la bande passante du résonateur résultant de conditions mécaniques liées à la géométrie du substrat de quartz et de la célérité de l’onde élastique qui s’y propage. Comme la célérité de l’onde élastique est liée au ratio de la constante mécanique (l’équivalent en matériau isotrope du module de Young) à la densité, tout changement de ces paramètres se traduit par une variation de la fréquence. La documentation technique indique que la tolérance de fabrication de ces résonateurs faible coût est ± 50 ppm, signifiant une variation relative de la fréquence à la valeur nominale de 50· 10⁻⁶. À 54 MHz, le résonateur peut donc présenter une fréquence effective de 54· 10⁶± 2700 Hz, écart à la valeur nominale dont une partie est fixe (géométrie) et une partie variable, notamment en fonction de la température. L’asservissement vise donc à corriger ces deux effets pour amener la fréquence de l’oscillateur à sa valeur nominale.

Les conditions d’oscillations de la boucle contenant l’amplificateur et le résonateur sont qualifiées de Barkhausen, avec la première condition grossière qui dicte que le gain de l’amplificateur compense les pertes, et la seconde fine qui affirme que la somme des phases dans la boucle est 0 [2π] afin que l’onde qui entre dans l’oscillateur se superpose à celle qui sort de l’amplificateur et que la puissance s’accumule de façon cohérente.

Ainsi, l’approche classique d’ajustement de fréquence consiste à jouer sur la condition de Barkhausen de phase en ajustant les condensateurs de pieds dans le montage d’oscillateur de Pierce équipant tout système numérique, par exemple en complétant un des condensateurs de pieds par une varicap, un condensateur variable commandable en tension. Cependant, nous observons que la fréquence naturelle du circuit (Fig. 9) fourni sur le modèle de CM4 que nous exploitons est déjà en deçà de la fréquence nominale de 1,5 kHz (Fig. 11), soit une valeur dans la tolérance de fabrication, mais que nous ne pourrons rattraper par une capacité de pieds additionnelle qui ne peut faire que descendre encore plus la fréquence. Dans ces conditions, il nous faut amener la fréquence de l’oscillateur au-dessus de la valeur nominale de 54 MHz pour que cette approche soit effective. Diverses références [12, section 1.3] indiquent que la seule façon d’augmenter la fréquence de l’oscillateur est d’amener une capacité C en série avec le résonateur. En effet, en insérant une vingtaine de pF entre le résonateur et un des condensateurs de pieds, nous constatons que la fréquence croît pour dépasser les 54 MHz nominaux, nous permettant d’envisager le contrôle par une capacité variable de pieds programmable en tension qu’est une varicap (Fig. 12). Nous proposons en fin de ce document une courte annexe qui développe la simulation du résonateur à onde de volume sous ngspice intégré dans KiCad (voir annexe A) et sous Qucs (voir annexe B).

Finalement, nous nous interrogeons sur la capacité de tirage du résonateur par rapport à la variation de fréquence du résonateur à quartz avec son environnement, et en particulier la température. En effet, les paramètres mécaniques de propagation de l’onde élastique vont varier avec la température, induisant une accélération ou un ralentissement observé comme variation de la fréquence à géométrie fixe [13]. Expérimentalement, il est facile de chauffer (du courant dans une résistance ou un transistor) alors que refroidir est compliqué (un module Peltier est encombrant et nécessite un radiateur sur sa face chaude) : nous constatons que l’orientation cristalline sélectionnée par le fabricant du résonateur induit une baisse de fréquence quand la température augmente (Fig. 13), impliquant qu’il faut garder un peu de marge si le circuit chauffe lors de son fonctionnement. Par ailleurs, cette mesure explique pourquoi on ne coupe jamais un oscillateur, son temps de stabilisation pouvant se compter en heures avant que la température ne soit homogène dans le très mauvais conducteur thermique qu’est le quartz.

Un dernier problème se pose : nous sommes capables d’observer la dérive du temps système par rapport au temps de référence PTP par la sauvegarde de fichiers contenant les informations acquises par la X310, mais comment établir l’écart de fréquence PTP-système en l’absence d’un tel montage de test ? La solution ne peut pas venir de ptp4l qui se charge exclusivement d’asservir l’horloge PTP de l’interface physique et ne s’intéresse pas au système : son champ freq n’est pas affecté par la fréquence qui cadence le processeur. Au contraire, phc2sys qui fait le lien entre PTP et le noyau contient l’information pertinente dans son champ freq tel que nous le vérifions sur le montage de test dans la Fig. 14. Nous avons ainsi volontairement décalé la fréquence de cadencement du processeur de sa valeur nominale et constatons que phc2sys indique un écart de fréquence égal à 18,5 fois la différence de fréquence en hertz, qui s’avère proche de 1000 ppm pour un oscillateur à 54 MHz (1000/54=18,519).

Le lecteur qui ne désire pas se battre avec des composants montés en surface assemblés en dead bug sur le circuit imprimé pourra acquérir un oscillateur du même facteur de forme que celui équipant la CM4 (noter qu’il s’agit d’un oscillateur et non d’un résonateur, cette fois), mais commandable en tension dans une gamme de ± 100 ppm qui doit permettre de compenser la tolérance de fabrication de ± 50 ppm, sous la forme de la référence ECS-2532VXO-540B-2.8 disponible pour 7,60 euros chez Digikey sous la nomenclature XC1488CT-ND. Le remplacement du résonateur par un oscillateur a son importance, car nous allons injecter une fréquence forcée au processeur de la CM4 au lieu de la laisser produire sa propre oscillation par le montage de Pierce. Il faut donc distinguer entrée et sortie de la porte inverseuse pour injecter le signal du bon côté (l’entrée de la porte). Empiriquement, nous avons constaté que c’est la broche la plus proche du symbole de la poubelle sur le circuit imprimé qui permet une telle injection de signal, l’autre (sortie de la porte logique) étant plus propice à l’observation de la fréquence par un compteur.

5. Serveur de temps PTP sur CM4 contrôlé par GNSS (GPS)

Sans nécessairement en être conscient, le commun des mortels a bien accès à une centaine d’horloges atomiques : il s’agit des constellations de navigation par satellite GPS américain, Galileo européen et Beidou chinois (Glonass russe avec sa diversité de fréquences est discutable pour le transfert de temps et nous l’omettrons de la discussion). Un récepteur UBlox Zed-F9P que nous avons déjà découvert auparavant [14] fait une excellente source de temps pour asservir une CM4 configurée en serveur PTP. La documentation proposée à [15] fournit un excellent point de départ pour mettre en œuvre un asservissement de l’horloge du noyau Linux sur l’information temporelle fournie par ce récepteur GPS sous la forme de son impulsion 1-PPS. En effet, la broche qui nous a servis auparavant à qualifier l’asservissement de l’interface physique sur PTP en la configurant comme une sortie 1-PPS peut aussi être configurée en entrée pour fournir le signal de datation de l’interface physique.

Cependant, il faut pouvoir non seulement recevoir une information de datation sous forme du signal 1-PPS, mais aussi lire les trames NMEA transmises par le récepteur GPS et contenant la date et l’heure. Dans le circuit MikroElektronika MIKROE-4456, le port UART compatible RS232 émet les trames NMEA au débit de 38400 bauds, cause de notre mise à jour de la version de linuxptp à la version 4 avec l’ajout de la configuration du baudrate dans le fichier de configuration. La latence induite par ce débit de communication relativement lent n’a pas d’importance sur la datation qui est définie uniquement sur le front montant du 1-PPS alors que le message transmis par RS232 n’a vocation qu’à identifier la date et l’heure associées à ce signal. Cependant, nous désirons conserver la console UART de la CM4 nommée ttyAMA0 pour déverminer les cas de dysfonctionnement de l’interface Ethernet, et utilisons donc un convertisseur série/USB qui se connecte sur le port USB-A de la carte Compute Module 4 IO Board. Il s’avère que nous devons manuellement activer le support du port USB de la CM4, sans quoi le régulateur de tension qui alimentera les périphériques ne sera pas activé :

Une fois l’interface de communication créée dans /dev/ttyUSB0, nous pouvons vérifier que les trames NMEA circulent et sont lisibles depuis la CM4 :

et nous attendons de voir des messages de position et de datation remplis, notamment GNGGA de la forme $GNGGA,050252.00,.... Il faut absolument que la solution de position soit fournie, sans quoi l’impulsion 1-PPS ne peut être produite.

L’asservissement d’un ordinateur sur GPS n’est pas complètement trivial, malgré les efforts de documentation à [15] sans lesquels ce résultat n’aurait pu être obtenu. La principale difficulté est la multiplicité des étapes, de la datation des trames de l’interface physique par le signal 1-PPS produit par le récepteur GPS, à la propagation de ce signal vers le noyau Linux puis vers l’horloge système. Pour le moment, nous restons sur une procédure manuelle qui mériterait d’être automatisée. Travaillant sur CM4 exécutant un système GNU Linux issu de Buildroot, nous ne nous appuierons pas sur systemd tel que préconisé dans la documentation, mais nous efforcerons de comprendre chaque étape lancée manuellement. Les quatre outils impliqués, tous disponibles dans Buildroot, seront :

• ts2phc utilisé pour synchroniser les horloges matérielles supportant PTP (PTP Hardware Clocks ou PHC) à un signal externe tel que l’impulsion 1-PPS venant d’un récepteur GPS proposant cette fonctionnalité (le Zed-F9P la fournit, bien entendu) ;
• phc2sys que nous avons déjà rencontré pour synchroniser le temps système du noyau avec le temps des PHC, mais cette fois en plaçant l’information de datation dans une mémoire partagée (SHM) avec un serveur NTP et en particulier chrony que nous mentionnons ci-dessous ;
• ptp4l se charge des boucles d’asservissement pour contrôler le temps de l’interface physique sur l’information fournie par le maître ;
• chrony qui vient sous la forme d’une paire daemon chronyd et l’applicatif pour sa configuration depuis l’espace utilisateur chronyc.

Découpons les étapes pour passer une CM4 en Grandmaster PTP commandé par GPS :

1. Nous commençons par tuer tout mécanisme de synchronisation qui pourrait interférer avec notre démonstration :

C’est un peu violent, mais ainsi nous savons où nous en sommes au départ, et en particulier avons volontairement retiré toute référence à un service NTP qui pourrait interférer avec nos mesures.

2. Nous passons la broche connectée au signal 1-PPS en entrée pour lire l’impulsion venant du récepteur GPS :

qui doit répondre quelque chose comme :

pour prouver que le signal 1-PPS est reçu. La date de l’évènement s’incrémente bien de 1 s.

3. Nous lançons l’asservissement de l’interface PTP sur le signal 1-PPS :

avec ptp_gps.config qui contient le port de communication avec le récepteur GPS et son débit de communication, ici pour une communication par convertisseur RS232-USB /dev/ttyUSB0, qu’on remplacera par ttyAMA0 si l’UART de la CM4 est utilisé après avoir désactivé la console dans cmdline.txt au démarrage :

Si tout se passe bien, le fichier ts2phc_gps.log nous informe, grâce au niveau de log 7 (tout afficher) dans un premier temps, que les trames NMEA sont bien lues et décodées pour être comprises :

Ensuite, nous vérifions que la réception des impulsions 1 PPS fonctionne bien et commande l’interface physique. Au cours de cette acquisition, grep offset ts2phc_gps.log doit indiquer un retard qui diminue pour tendre vers quelques nanosecondes de la forme :

Autant dans ce fichier de log que lorsque nous lisons les statuts dans /tmp/message*, [16] nous informe de l’état de l’asservissement selon s0=unlocked, s1=clock step et s2=locked.

Si lors de son lancement, ts2phc se plaint que ts2phc[3760.610]: nmea: utc time is past leap second table expiry date alors soit le fichier qui informe du nombre de secondes intercalaires a expiré avant la date actuelle, soit il est simplement inexistant (ce fut le cas dans Buildroot). Dans les deux cas, on pourra chercher à https://www.ietf.org/timezones/data/leap-seconds.list sa dernière version et placer le fichier dans /usr/share/zoneinfo en s’assurant que la date d’expiration :

est postérieure à la date courante.

Cette étape d’asservissement de PTP sur GPS validée, le processus ts2phc est tué puisque nous le relancerons ultérieurement dans une configuration différente.

Maintenant que nous sommes persuadés que le 1-PPS GPS est vu par l’interface PTP, nous devons configurer la CM4 comme grand maître PTP asservi sur GPS.

1. Après avoir tué le processus ts2phc, lancé manuellement auparavant, par killall ts2phc, nous consultons les variables d’environnement proposées à https://github.com/jclark/rpi-cm4-ptp-guide/blob/main/files/ptp4l-gm qui règlent les paramètres du grand maître pour encourager ses esclaves à écouter ses consignes.

2. Nous lançons ptp4l en exploitant l’interface Ethernet (-2 pour IEEE802.3, en opposition à IP) :

qui nous indiquera dans /var/log/messages que :

3. Nous utilisons le PTP Management Client pmc pour configurer le grand maître :

avec la clockAccuracy qui définit la performance de la synchronisation, ici 1 µs pour 0x23 (allant de 0x20 pour 25 ns à 0x25 pour 10 µs). Nous pourrons à tout moment vérifier la validité de cette configuration par pmc -u -b 0 'get GRANDMASTER_SETTING_NP'.

4. Nous lançons phc2sys qui fait le lien entre horloge PTP et système avec :

Ici, ts2phc se contente d’un niveau de log de 6 puisque nous avons déjà validé auparavant son bon fonctionnement et voulons éviter de remplir inutilement /tmp/messages de toutes les trames NMEA lues, tout en reprenant la configuration du port série de communication dans ptp_gps.config.

Si /var/log/messages indique ts2phc: [XXX.YYY] source ts not valid, nous avons constaté qu’un stty -F /dev/ttyUSB0 38400 && cat < /dev/ttyUSB0 permet de le réveiller.

Finalement, le daemon chronyd a normalement été lancé au démarrage du système, afin que son outil associé chronyc en espace utilisateur qui prend en argument sources puisse valider que seul le GPS est utilisé pour asservir le temps et lire les trames NMEA pour connaître la date, et non pas un autre serveur PTP ou NTP. Ainsi, une fois toutes ces étapes complétées, la commande chronyc sources doit donner une unique source de la forme :

avec un nombre de mesures lues initialement nul, mais qui finiront pas s’incrémenter avec un délai. Avec un peu de patience, nous finirons par obtenir :

Le fichier /etc/chrony.conf contient un grand nombre d’options, mais la plus importante semble être :

parmi :

Une fois que tous les asservissements fonctionnent, /tmp/messages montrera :

Nous discuterons du statut s0 de phc2sys ci-dessous, mais chrony qui prend en charge la distribution du temps compte tenu de l’option -E ntpshm (NTP Shared Memory décrit à https://www.ntp.org/documentation/drivers/driver28/) indique par chronyc tracking que :

qui n’est pas stupide quand le compteur de fréquence indique 53999625 ou un écart de (53999625−54·10⁶)/54=−6.9 ppm. Au contraire :

indique que l’horloge est trop rapide de 2,128 ppm, en accord avec l’observation d’une fréquence d’oscillateur de 54 MHz+46 Hz.

Nous avions auparavant confirmé que l’argument freq de phc2sys est représentatif de l’écart de fréquence à la valeur nominale (Fig. 14), mais en lisant les logs, nous constatons qu’avec la configuration qui s’appuie sur chrony, le statut de phc2sys reste à s0 (unlocked). Même si J. Clark affirme préférer chrony pour sa souplesse de configuration, le fait est que son information d’erreur de fréquence en ppm (partie par million) est peu précise et difficilement exploitable. Nous pouvons revenir au fonctionnement précédent en retirant le partage de mémoire avec chrony tel qu’il était configuré par -E ntpshm pour le remplacer par -E pi choisi par défaut, qui active le contrôleur proportionnel intégral qui une fois accroché indique à nouveau :

avec s2 pour indiquer que l’asservissement fonctionne. C’est cette information de fréquence freq que nous allons utiliser pour asservir la fréquence d’oscillation en ajustant la capacité de tirage. Cependant, la CM4 ne possède pas de convertisseur analogique-numérique qui pourrait polariser la varicap : nous allons user d’un autre stratagème pour produire le signal de commande. Notez dès à présent que l’asservissement proportionnel intégral de -E pi sera source d’ennuis et sera remplacé finalement par -E linreg.

6. syntonisation de la CM4 sur l’impulsion 1-PPS GPS

Le processeur de la CM4 propose un certain nombre de broches supportant la modulation en largeur d’impulsion (Pulse Width Modulation PWM) commandée non pas par logiciel, mais par un compteur matériel donc immune aux fluctuations de charge du processeur généraliste. Une PWM produit, après passage du signal de période fixe, mais de rapport cyclique variable dans un filtre passe-bas une tension constante entre 0 et sa tension maximale, égale au rapport de la tension maximale au rapport cyclique.

La configuration de la PWM est supportée par python-pigpio disponible comme paquet dans Buildroot en complément du daemon pigpio que nous devrons aussi compiler pour la cible. Une fois ces outils disponibles :

configure la broche 18 pour générer une PWM de fréquence 1 MHz et de rapport cyclique de 75 %. Ainsi, bien que la CM4 ne possède pas de convertisseur analogique-numérique, le VCO est contrôlé par la PWM dont le rapport cyclique détermine la tension de polarisation une fois filtrée par un circuit RC de fréquence de coupure bien inférieur à la fréquence de la PWM. Afin de ne pas s’encombrer de Python, il semble plus facile, en shell, de commander :

pour définir la fréquence de la PWM de la broche 18 à 2 MHz et de rapport cyclique 20 %. Cependant, le choix de la fréquence de la PWM fPWM est un compromis entre la capacité à filtrer la sortie oscillante pour produire un signal de commande continu, et la résolution de la commande puisque le nombre de rapports cycliques est égal à 375· 10⁶/fPWM [17]. En effet, choisir une fréquence élevée rend le filtrage plus aisé avec un simple filtre passe-bas RC, mais réduit la granularité de la commande. Ainsi, pour une commande sur 12 bits, la fréquence de la PWM sera limitée à un peu moins de 100 kHz et le filtre passe-bas devra couper à une fraction de cette fréquence, laissant tout de même assez de marge pour mettre à jour la tension de polarisation de la varicap et ajuster la fréquence selon l’information fournie périodiquement par phc2sys (Fig. 14).

Avant tout asservissement, nous validons la capacité de tirage de l’oscillateur en boucle ouverte. Pour ce faire, la tension de commande étant limitée à 0-3,3 V par la PWM filtrée, nous devons identifier une varicap capable de faire varier la capacité dans cette gamme de tensions. Le composant SMV1272 de Skyworks semble parfaitement adapté avec une capacité qui varie de 16 à 6 pF entre 1 et 3,3 V pour monter à près de 30 pF à 0 V de polarisation, suffisamment proche des 18 pF des condensateurs de pieds du montage Pierce seul pour ne pas faire décrocher l’oscillateur. Nous avons cependant constaté qu’il est peu judicieux de trop baisser la tension de commande, la CM4 cessant de fonctionner si son oscillateur devient instable. La caractéristique en boucle ouverte de la fréquence d’oscillation en fonction de la tension est fournie en Fig. 16 ou 17 selon les modèles, mais devra être reévaluée par chaque CM4, la gamme de tirage étant relativement réduite cependant. Néanmoins en accord avec les attentes (annexe A), augmenter la tension de polarisation de la varicap abaisse la capacité en parallèle du condensateur de pieds et fait monter la fréquence de l’oscillateur.

D’ailleurs, on peut même se demander pourquoi se fatiguer à commander la fréquence de l’oscillateur et ne pas le laisser vivre tranquillement sa vie. La Fig. 18 illustre l’impact du changement de température du résonateur, que nous avions mentionné auparavant en chauffant par un fer à souder, mais cette fois simplement lors de la mise sous tension de la CM4 avec son processeur à basse fréquence par la configuration par défaut de Buildroot (powersave) puis le passage au cadencement le plus rapide (performance) avec l’augmentation de fréquence qui se traduit immédiatement par une consommation accrue et donc une élévation de température. Lors du passage de la fréquence de cadencement du processeur de 600 à 1500 MHz, la consommation globale de la carte Compute Module 4 IO passe de 230 mA à 300 mA sous 5 V, soit un passage de la consommation globale de 1,15 W à 1,5 W. Ce résultat est en accord avec celui présenté à http://www.ntp.org/ntpfaq/NTP-s-sw-clocks-quality/ où « the frequency of the oscillator’s correction value increases by about 11 PPM after powering up the system. This is quite likely due to the increase of temperature. »

La finalité de cette présentation tient donc en un script bash qui périodiquement sonde la fréquence de l’oscillateur, par exemple en recherchant (tail /var/log/messages) les dernières informations de phc2sys dans les logs du système, pour en extraire l’information du champ freq et commander par pigs la PWM en conséquent. La principale subtilité tient aux protections contre les dysfonctionnements (messages autres que ceux de phc2sys), contre les valeurs aberrantes, et contre les commandes en dehors des plages autorisées. Le script s’allonge donc petit à petit avec les conditions de protection if () ;then ... fi pour se conclure en :

Le script commence par initialiser des variables et notamment la commande command, partant d’une valeur qui place l’oscillateur pas trop loin de la fréquence visée de 54 MHz, c.-⁠à-⁠d. l’argument de pigs qui produit un rapport cyclique qui polarise la varicap afin d’ajuster l’oscillateur convenablement. Nous verrons ci-dessous pourquoi nous aurons besoin d’une moyenne glissante sur un nombre pair de valeurs mesmi avec i∈[1:4] les valeurs passées de la mesure, et un compteur de parité pair. Nous implémentons un correcteur de type proportionnel intégral tel que commandn=Kp·erreur_n+K_i∫₁ⁿ erreur_n avec erreur l’erreur de fréquence fournie par phc2sys que nous cherchons à annuler. Il est classique dans ce contexte de calculer command_n+1−command_n=K_p(erreur_n+1−erreur_n)+K_i erreur_n afin d’éviter d’accumuler une intégrale qui pourrait diverger, et ainsi ne calculer que l’évolution de la commande de la forme command_n+1=command_n+K_p(erreur_n+1−erreur_n)+K_i erreur_n. Une fois la commande calculée, nous vérifions que la valeur de la PWM est dans la gamme autorisée entre 0 et 10⁶, avant de commander la PWM. La majorité des tests vise à vérifier que les arguments sont des nombres et ne contiennent pas de chaîne de caractères qui feraient planter les opérations arithmétiques, notamment lors de la mise à jour de la commande qui fait intervenir cmdp et cmdi les évolutions par le terme proportionnel et le terme intégral. Par ailleurs, on notera que bc de Buildroot, qui effectue toujours des opérations avec des décimales que la variable scale ne permet pas d’ajuster, ne se comporte pas comme celui de notre système Debian/GNU Linux qui par défaut, en l’absence de l’option -l, fournit des résultats entiers tel que nous les recherchions, forçant un appel à sed pour éliminer la partie fractionnaire.

Nous avons constaté que l’oscillateur varie sur une plage de 3250 Hz entre une tension de polarisation de la varicap de 0 V à 3,3 V. Nous savons que le nombre de pas de commande de la PWM de fréquence f est 375·10⁶/f donc 3750 pas lorsque f=100 kHz. Ainsi, un pas de fréquence varie la fréquence d’oscillation de 3250/3750=0,87 Hz et le meilleur asservissement que nous pouvons espérer est 0,87/54=0,016 ppm ou 16· 10⁻⁹. Ce n’est pas terrible, mais mieux que rien.

La surprise vient de l’observation du champ freq de phc2sys extrait de /var/log/messages en garantissant de ne prendre que les valeurs successives, ne connaissant pas le taux de rafraîchissement du message, en rejetant les nouvelles valeurs égales aux anciennes. Nous constatons que les mesures fluctuent énormément d’une estimation à l’autre... mais que la moyenne des valeurs deux par deux donne une bonne estimation de la fréquence de l’oscillateur. La cause de ce fonctionnement n’est pas connue, mais c’est un constat : en moyennant (conv(...,[1 1]) sous GNU Octave) un nombre pair de mesures, nous éliminons les fluctuations et obtenons un estimateur de l’écart de fréquence de l’oscillateur à la fréquence GPS exploitable (Fig. 19).

Nous avons la mesure sous la forme du champ freq de phc2sys dans /var/log/messages, nous avons la commande sous la forme de l’argument de pigs pour modifier la tension de polarisation de la varicap, nous avons la caractérisation en boucle ouverte, il ne reste plus qu’à fermer la boucle et asservir l’oscillateur de la CM4 sur GPS.

Dans un premier temps, un asservissement proportionnel avec K_p=0.1 et K_i=0 permet de s’approprier le comportement du système. Nous savons que la solution sera biaisée en l’absence de l’élimination de l’erreur constante par le terme intégral, mais au moins on aura un résultat (Fig. 20).

De cette première mesure, nous apprenons que :

• chaque mesure individuelle est excessivement bruitée, mais les mesures prises deux par deux compensent les fluctuations énormes entre estimations successives pour fournir une valeur moyenne représentative de l’écart de fréquence de l’oscillateur qui cadence le processeur à la valeur nominale (Fig. 19) ;
• néanmoins avec le contrôleur -E pi de phc2sys, nous avons été incapables d’obtenir un asservissement pendant plus de quelques heures, après lesquelles les valeurs successives des estimations de freq divergent vers des valeurs de plus de 105 que l’arithmétique de bash n’arrive plus à correctement appréhender, induisant une divergence de notre propre boucle d’asservissement et l’absence de correction qui a dépassé la gamme des commandes que peut comprendre la PWM. Il est de toute façon compliqué d’obtenir une estimation fiable d’écart de fréquence de quelques unités quand les valeurs successives fournies par phc2sys diffèrent de plusieurs centaines de milliers ;
• les corrections à court terme, une fois toutes les 15 secondes environ, au rythme du rafraîchissement des messages de phc2sys, sont plus néfastes que bénéfiques à la stabilité de l’oscillateur, mais qu’à long terme ou en présence de perturbations telles qu’une fenêtre ouverte qui refroidit le circuit par un courant d’air, la correction est utile (Fig. 20). Cette observation se formalise par le calcul de la variance d’Allan des mesures de fréquences (Fig. 21) : au-delà de quelques centaines à milliers de secondes (1 h d’intégration), la courbe corrigée bleue passe en dessous de la courbe libre rouge, indiquant que la stabilisation a eu un effet positif. Les barres d’erreurs attestent de la validité de la conclusion.

Le deuxième point est corrigé en remplaçant la correction -E pi de phc2sys par -E linreg qui stabilise l’estimation de freq et la maintient stable pendant plusieurs heures, tel qu’inspiré du commentaire à https://www.mail-archive.com/linuxptp-users@lists.sourceforge.net/msg02297.html concernant la précision de l’estimation d’écart de fréquence par phc2sys. Apparemment, linreg est plus gourmand en ressources de calcul que pi, mais cela ne semble pas importer pour une CM4, n’incluant que des opérations arithmétiques déterministes (https://github.com/nxp-archive/openil_linuxptp/blob/master/linreg.c). De cette façon, les écarts de fréquence estimés par phc2sys restent, une fois l’asservissement fonctionnel, de quelques unités même 24 h après avoir lancé la mesure, permettant de maintenir la boucle de contrôle de l’oscillateur fermée.

Le correcteur PI converge vers 53,999960 MHz ou un biais de -40 Hz ou -0,9 ppm à la consigne de 54 MHz lors d’une mesure avec un compteur Agilent 53131A cadencé par son pilote interne. Ce pilote a été mesuré a posteriori comme biaisé de -5 Hz à 10 MHz sur une référence métrologique, ou -0,5 ppm. Ces valeurs ne sont pas aberrantes vis-à-vis de la documentation technique Agilent 53131A/132A 225 MHz Universal Counter Operating Guide (page 3-4) qui indique un taux de vieillissement annuel de 0,3 ppm/mois de cet oscillateur dans sa version standard, pour être réduit d’un facteur 10 quand un oscillateur thermostaté (OCXO) est utilisé.

En conclusion de cette étude, nous démontrons le bénéfice de corriger, à long terme, l’oscillateur soumis aux aléas de son environnement sur une référence stable qu’est l’impulsion 1-PPS GPS (Fig. 22).

Ce faisant, du fait d’une correction trop rapide polluée par une mesure grossière de la fréquence par phc2sys et d’un pas de correction insuffisamment précis, nous avons dégradé la stabilité court terme de l’oscillateur. Fort de Fig. 21, nous constatons que l’intersection entre la courbe libre et la courbe asservie se trouve sur un temps d’intégration de quelques centaines de secondes, qui indique que la constante de temps de l’asservissement devrait être de quelques dizaines d’échantillons acquis dans /var/log/messages toutes les 15 secondes environ. La résolution de la correction égale à 0,87 Hz ne devrait pas handicaper le contrôleur en l’état, mais un « vrai » DAC sur bus SPI ou I²C ne pourrait qu’être bénéfique pour réduire le pas de correction. Il est fort probable qu’un lecteur compétent en automatique sache mieux régler les coefficients du correcteur proportionnel et intégral à la vue de la réponse indicielle de la Fig. 22, puisque les oscillations résiduelles lors du retour à la consigne sont clairement visibles dans les encadrés en haut à gauche.

Conclusion

Nous avons abordé l’utilisation de l’information temporelle disponible auprès d’un noyau Linux et en pratique la datation des fichiers, et ce dans un contexte de synchronisation d’un réseau distribuant les ressources. Nous avons décrit les deux modes de synchronisation par logiciel NTP et par matériel PTP dans des conditions réelles et idéales en contrôlant tous les instruments sur une même source de fréquence supposée parfaite. Ce faisant, nous avons découvert l’impact de la fréquence du compteur qui définit le temps dans le noyau, et identifié la nécessité de syntoniser l’oscillateur qui cadence le processeur, en plus de le synchroniser. Finalement, nous avons étendu cette solution à tout possesseur d’un récepteur GPS capable de fournir l’horodatage qu’est l’impulsion 1-PPS qui fournit alors la source de synchronisation PTP. Une solution d’asservissement de l’oscillateur qui cadence le processeur de la Raspberry Pi Compute Module 4 a été proposée. Sans prétendre atteindre les performances de White Rabbit – en l’état tout au moins – la syntonisation du processeur sur le signal PTP semble amener la perspective d’exploiter le signal de datation précis au noyau et donc à l’espace utilisateur.

Au-delà de la solution matérielle de syntonisation proposée, nos explorations de la gestion du temps par le noyau Linux nous ont amenés à découvrir l’appel système adjtimex et l’outil en espace utilisateur qui lui est associé dans Busybox de Buildroot dans misc → adjtimex, mais qui se contente d’afficher l’erreur relative de fréquence sans proposer de valeur absolue. Ainsi, http://www.ep.ph.bham.ac.uk/general/support/adjtimex.html explore la gestion du temps par cet outil, mais nous n’avons pas persévéré dans cette voie qui reste ouverte de modifier non pas physiquement l’oscillateur qui cadence le processeur, mais la perception du temps qu’a le noyau cadencé par un oscillateur faux.

Il semble donc peu probable que l’information temporelle fine fournie par PTP soit exploitable lors des appels système du noyau Linux. La seule utilité de la synchronisation des interfaces physiques Ethernet reliées au réseau informatique reste donc la production de l’impulsion 1-PPS en vue de générer un signal radiofréquence physique cohérent, par exemple au moyen du « Network Clock Generator/Synchronizer » AD9548 de Analog Devices qui produit un signal jusqu’à 450 MHz asservi sur une entrée 1-PPS (Fig. 23).

Remerciements

Cette étude est un effet de bord imprévu d’un projet concernant le transfert de temps par satellite géostationnaire qui nécessite de synchroniser la date de sauvegarde de fichiers à Paris et Besançon en s’appuyant sur une base de temps commune échangée par NTP : Baptiste Chupin et Olivier Chiu du SYRTE/Observatoire de Paris ont proposé l’idée de dater les fichiers de sauvegarde par stat. Ledit projet est soutenu financièrement par le Laboratoire National d’Essais (LNE) et le Labex FIRST-TF https://first-tf.fr/ que nous remercions pour la motivation d’étudier la stabilité en fréquence de la Raspberry Pi Compute Module 4. L’accès à des ressources quasi infinies d’un laboratoire de recherche public, et en particulier les références de temps et fréquences métrologiques, facilite l’obtention rapide de résultats, mais nous ne pouvons qu’encourager tout amateur éclairé à reproduire ces résultats. Malgré la volonté de faire disparaître la piézoélectricité de FEMTO-ST, Serge Galliou (ENSMM, Besançon) a encore pu partager son expérience de conception des oscillateurs à quartz et fourni de précieuses informations sur le tirage capacitif pour élever la fréquence d’oscillation.

A. Modélisation du résonateur à quartz dans ngspice sous KiCad

Le simulateur de circuits électroniques ngspice est désormais intégré dans KiCad. Afin de simuler les conditions de Barkhausen du résonateur muni de ses deux condensateurs de pieds et éventuellement d’une capacité de tirage en série, nous devons savoir comment modéliser le résonateur. Nous omettrons la porte logique supposée idéale, de gain infini et de rotation de phase de 180° comme toute porte inverseuse qui se respecte.

Comme tout circuit résonnant, un résonateur à quartz se modélise par une équation différentielle du second ordre, donc un circuit RLC en électronique. Dans cette branche dite motionnelle, la résistance R₁ représente les pertes (acoustiques pour le système physique), l’inductance L₁ la masse équivalente, et la capacité C₁ la raideur du ressort équivalent. Connaissant le facteur de qualité Q=1/R₁√L₁/C₁ et la fréquence de résonance f=1/(2π√L₁C₁), nous avons deux équations et trois variables à déterminer. Cependant, une originalité du résonateur à quartz par rapport au circuit RLC est d’être formé d’un morceau de diélectrique piézoélectrique – ici le quartz – couvert de deux électrodes. Deux électrodes de part et d’autre d’un diélectrique forment un condensateur C₀=ε₀ε_r S/d avec S la surface des électrodes, d l’épaisseur du substrat de quartz de permittivité relative ε_r qui détermine l’espacement entre les électrodes. On montre [18] que le ratio C₀/C₁ est déterminé par le coefficient de couplage électromécanique du substrat piézoélectrique, une propriété intrinsèque du matériau pour une orientation cristalline donnée. Si C₀ est donné par la géométrie et C1 par la nature du matériau, il ne reste plus de degré de liberté pour trouver R₁ et C₁. En pratique C₀ et C₁ sont donnés par le constructeur dans sa documentation technique (Fig. 11, droite avec le champ C₀) et nous en déduisons les autres paramètres utiles.

Nous dessinons le circuit RLC série avec sa capacité parallèle – dit modèle de Butterworh-van Dyke – avec les valeurs de composants qui permettent de simuler ici un résonateur à 16 MHz. Nous ajoutons la capacité C₂ en série et les deux capacités de pieds C₃ et C₆ pour tenter d’atteindre la condition de Barkhausen en phase d’une rotation globale de 180°. Afin de mesurer une fonction de transfert S₂₁, nous excitons un côté avec une source de tension en série avec une impédance limitant le courant que peut fournir la porte logique, et chargeons par une impédance représentative de l’impédance en entrée de la porte logique. La source de tension s’obtient dans les composants KiCad en effectuant une recherche sur le mot clé « spice » qui propose une liste de symboles non routables mais utiles à la simulation (Fig. 24). Les paramètres de la source sont fournis dans son champ Value avec une valeur de tension DC nulle et une amplitude de la composante alternative unitaire. La nature de la simulation est fournie comme texte libre dans le schéma comme nous le ferions avec ngspice, à savoir une fonction de transfert spectrale avec un axe des fréquences qui s’incrémente linéairement autour de la résonance à 16 MHz : .ac lin 1001 15.99meg 16.02meg en se rappelant que sous SPICE, « m » comme « M » représentent le milli (10⁻³) tandis que le million (10⁶) se nomme « meg »... c’est aussi valable pour les résistances.

Le schéma rempli, sous KiCad 7 nous sélectionnons le menu Inspect → Simulator... et une fois la fenêtre de ngspice lancée, nous sélectionnons Sim Parameters → Custom → Load directives from schematic, nous lançons la simulation par la flèche, et sélectionnons les signaux à afficher avec la sonde Probe. Nous pouvons faire varier un composant, par exemple C2, en plaçant le tournevis Tune sur ce composant (Fig. 25).

Cependant, la sortie d’écran de ngspice est hideuse, ne permet pas d’accumuler des graphiques ou d’automatiser la simulation : nous revenons donc aux fondamentaux en exportant la netlist par Simulation → Show SPICE netlist que nous sauvons (Fig. 25, étape 5) dans un fichier texte (par convention d’extension .cir mais sans importance), et sous ngspice dans un terminal source fichier.cir suivi de la commande de simulation ac lin ... permet de relancer la simulation dont le résultat est sauvé dans un fichier sauve par print V(Net-(C2-Pad1)) > sauve pour être traité avec son outil favori (GNU Octave ou gnuplot par exemple). Le résultat est fourni en Fig. 26, avec la condition asymptotique de l’absence de condensateur en série pour la fréquence de résonance la plus basse, un tirage maximal pour la valeur de condensateur la plus faible, et une évolution continue entre les deux, puisque l’absence de condensateur revient au cas de la capacité infinie (|Z|=1/(Cω) → 0 si C→∞).

Nous comprenons ici pourquoi on dit qu’un oscillateur peut être tiré entre la résonance – minimum d’impédance – et l’anti-résonance, maximum d’impédance que nous constatons être insensible à la capacité série (mais très sensible à toute capacité parallèle, puisque produite par C₀) et que donc les résonateurs en matériau piézoélectrique faiblement couplé tel que le quartz ne permettent qu’une correction modeste de la fréquence d’oscillation.

B. Modélisation du résonateur à quartz dans Qucs

Modéliser un résonateur sous SPICE impose de fournir un circuit équivalent en composants discrets R, L, C qui peut être plus ou moins exact en fonction des éléments parasites qui entourent le composant, par exemple fils de connectique ou capacités parasites du boîtier. Il est classique en mesure de dispositifs radiofréquences de caractériser la réponse spectrale en module et en phase : un instrument dédié à cette mesure est l’analyseur de réseau vectoriel qui mesure les caractéristiques de l’onde réfléchie (et transmise le cas échéant) en fonction de la fréquence définie par l’utilisateur [19]. De cette mesure de la fonction de transfert du dispositif, nous devons pouvoir déduire l’impact des éléments entourant le dispositif analysé, par exemple les condensateurs de pieds dans le montage Pierce ou la capacité série de tirage.

Le format standard d’une mesure par analyseur de réseau vectoriel se nomme le format Touchstone, ou SnP lors de la mesure de n ports. Ce format commence avec un entête qui annonce la nature de la mesure, l’impédance de référence, puis autant de colonnes que nécessaire pour contenir d’abord la fréquence, puis les coefficients complexes de réflexion et éventuellement de transmission de l’onde. Pour un résonateur qui ne contient qu’un port (deux broches), seul le coefficient de réflexion importe et la mesure de S₁₁ ne contient que trois colonnes, la fréquence suivie de la partie réelle et de la partie imaginaire du coefficient de réflexion. Notre fichier de mesure est disponible à http://jmfriedt.free.fr/resonateur54MHz.s1p.

Cependant, SPICE ne sait pas s’accommoder d’un fichier SnP, il nous faut un autre outil pour analyser un tel fichier. L’outil propriétaire classique de Agilent (maintenant Keysight) se nomme ADS pour Advanced Design System. Une tentative de version libre de cet outil se nomme Qucs, Quite Universal Circuit Simulator. Bien que nombre de fonctionnalités d’ADS manquent dans Qucs, ce dernier sera suffisant pour ce qui nous importe. Malheureusement, Qucs a bien du mal à rester en vie, et tenter de compiler depuis les sources sur une distribution Debian/sid actuelle se solde par un logiciel qui crashe à la moindre sélection de menus. Nous avons dû nous résoudre à utiliser une distribution binaire telle que décrite dans https://snapcraft.io/qucs-spice. Une fois ce paquet installé, nous lançons /snap/qucs-spice/qucs-spice.qucs pour obtenir une fenêtre de la forme de celle proposée en Fig. 27 (gauche). Nous créons un nouveau projet, choisissons dans le menu Components à gauche les lumped components pour une résistance et trois condensateurs, et sous file components un bloc 1-port S parameter file. Ce dernier bloc est renseigné du nom et chemin du fichier S1P et le menu Edit permet de vérifier que le fichier a été convenablement interprété. Finalement, nous ajoutons la nature de la simulation sous forme de simulations → S-parameter, simulation que nous paramétrons avec la gamme de fréquences de la mesure S1P et le même nombre de points que la mesure – dans notre cas 53,98 MHz à 54,01 MHz en 1201 points. Il est inutile, voire faux, d’étendre l’analyse au-delà de la gamme de mesure du fichier S1P puisque Qucs n’aura aucune information sur le comportement du composant en dehors de sa gamme de caractérisation. La position du port de mesure est ajoutée par sources → power sources qui indique l’impédance caractéristique par rapport à laquelle le coefficient de réflexion est calculé.

Enfin, nous définissons la nature de l’affichage, à savoir diagrams → Cartesian. Dans la fenêtre nouvellement créée, double-cliquer sur le cadre permet de sélectionner la nature de l’affichage. Comme nous avons défini (Insert → Insert Equation) un affichage en décibels par dBS11=dB(S(1,1)), nous avons l’option dans le graphique de double-cliquer sur dBS11 en fonction de frequency pour afficher le résultat de la simulation produite par F2 ou Simulation → Simulate.

Puisque nous désirons appréhender l’impact de varier le condensateur en série C3 et que comme d’habitude, un outil de simulation n’a pas pour rôle de produire une sortie graphique esthétique, nous désirons sauver le résultat de la simulation pour l’importer dans GNU Octave ou gnuplot. La seule façon que nous avons trouvée de conserver trace de la simulation est de copier $HOME/snap/qucs-spice/common/.qucs/projet/projet.dat et de l’éditer pour le rendre compatible avec Octave. Le résultat de la Fig. 27 est en parfait accord avec la modélisation SPICE proposée auparavant, mais en s’appuyant cette fois sur un vrai fichier de mesures et non un ajustement par un modèle s’approchant du comportement du résonateur.

La nouvelle mouture de Qucs mise à jour à https://github.com/ra3xdh/qucs_s ne supporte pas nativement le chargement des fichiers au format Touchstone, mais vise à s’appuyer sur le convertisseur vers un modèle SPICE par https://github.com/transmitterdan/s2spice qui une fois fonctionnel affranchira totalement de la dépendance à Qucs pour fournir une solution exclusivement ngspice une fois que les sources de tension et de courant dépendantes de la fréquence auront fini d’être implémentées.

Références

[1] Oleg Obleukhov, Ahmad Byagowi, How Precision Time Protocol is being deployed at Meta à https://engineering.fb.com/2022/11/21/production-engineering/precision-time-protocol-at-meta/

[2] Ahmad Byagowi, Oleg Obleukhov, PTP: Timing accuracy and precision for the future of computing à https://engineering.fb.com/2022/11/21/production-engineering/future-computing-ptp/

[3] P. Boven, Synchronization for interferometry through White Rabbit, European GNU Radio Days (2023) à https://www.youtube.com/watch?v=-rt0mQtxn64 à 7’35” formalisé dans A.R. Thompson & al., Interferometry and Synthesis in Radio Astronomy, Springer Open (2017) disponible à https://link.springer.com/book/10.1007/978-3-319-44431-4 (pp. 434–448).

[4] Time-stamping and business clocks synchronisation under MiFID II indique que les horloges datant les transactions rapides doivent diverger du temps universel coordonné UTC de 100 µs au plus et horodater à la microseconde à https://emissions-euets.com/time-stamping-and-business-clocks-synchronisation

[5] Jeff Geerling, PTP and IEEE-1588 hardware timestamping on the Raspberry Pi CM4 à https://www.jeffgeerling.com/blog/2022/ptp-and-ieee-1588-hardware-timestamping-on-raspberry-pi-cm4

[6] D.L. Mills, On the chronometry and metrology of computer network timescales and their application to the Network Time Protocol, Proc. ACM SIGCOMM Computer Communication Review 21(5) 8–17 (1991) à https://www.eecis.udel.edu/~mills/database/papers/time.pdf

[7] G. Goavec-Merou, J.-M Friedt, F. Meyer, Leurrage du GPS par radio logicielle, MISC HS, févr. 2019.

[8] Leapsecond, Motorola GPS M12+ Sawtooth à http://www.leapsecond.com/pages/m12/sawtooth.htm

[9] Security Requirements of Time Protocols in Packet Switched Networks (2014) à
https://www.rfc-editor.org/rfc/rfc7384.txt

[10] A. Malhotra & al., The Security of NTP’s Datagram Protocol, Cryptology ePrint Archive, Paper 2016/1006 (2016) à https://eprint.iacr.org/2016/1006

[11] Commit https://ohwr.org/project/white-rabbit/commit/eee7859a331d3b15811cac6e0ef06be26dd63255 de J. Serrano indiquant « Delegating support to WR commercial providers was part of our scalability strategy but did not really work ; Some WR developers at CERN moved on to other projects ; This combined with the increasing uptake of the technology in many areas raises a sustainability issue. », 26 juillet 2023.

[12] Geyer Quartz Technologies, Short Tutorial on Quartz Crystals and Oscillators (2022) à
https://www.geyer-electronic.de/wp-content/uploads/2022/11/GEYER-Quarz-Tutorial_e_07_22_V1.0.pdf

[13] un résonateur à onde de volume tel que ceux qui cadencent les systèmes numériques synchrones est formé d’un substrat de matériau piézoélectrique – généralement le quartz – qui convertit le signal électrique en onde mécanique. Comme dans un interféromètre optique de Fabry-Pérot, l’onde élastique est confinée dans le morceau de quartz d’épaisseur e et la condition de résonance à longueur d’onde λ vérifie e=N·λ/2, N∈ N impair. Pour un mode fondamental tel que le résonateur 54 MHz qui équipe la CM4, N=1 et λ=c/f avec c la célérité de l’onde élastique de l’ordre de 5000 m/s et f=54 MHz indique que e≃ 44 µm. Puisque c dépend de la température ou la contrainte, à e fixe nous observerons f varier.

[14] J.-M Friedt, Communication LoRa au moyen de RIOT-OS pour la mesure centimétrique par GPS différentiel avec RTKLib, Hackable 45, nov.-déc. 2022 https://connect.ed-diamond.com/hackable/hk-045/communication-lora-au-moyen-de-riot-os-pour-la-mesure-centimetrique-par-gps-differentiel-avec-rtklib

[15] James Clark, Guide to using the hardware PTP support in the Raspberry Pi CM4 (juillet 2023) à https://github.com/jclark/rpi-cm4-ptp-guide/

[16] GPS Grandmaster with ARM embedded Linux and SNMP (2022) à
https://www.embien.com/blog/gps-grandmaster-with-arm-embedded-linux/

[17] Documentation pigpio et en particulier la section sur les PWM matérielles à http://abyz.me.uk/rpi/pigpio/python.html#hardware_PWM

[18] J. Vig, Quartz Crystal Resonators and Oscillators – For Frequency Control and Timing Applications – A Tutorial (2014) à https://www.researchgate.net/publication/272177403_Quartz_Crystal_Resonators_and_Oscillators_-_For_Frequency_Control_and_Timing_Applications_-_A_Tutorial

[19] J.-M. Friedt, Introduction à l’analyseur de réseau : le NanoVNA pour la caractérisation spectrale de dispositifs radiofréquences, Hackable 36 (2021) - https://connect.ed-diamond.com/Hackable/hk-036/introduction-a-l-analyseur-de-reseau-le-nanovna-pour-la-caracterisation-spectrale-de-dispositifs-radiofrequences