Comment vérifier si la synchronisation PTP à double-capteur est normale

L'essentiel pour vérifier si la synchronisation PTP à double-capteur est normale consiste à vérifier si le décalage temporel est stable dans la plage des microsecondes et si l'état du maître-esclave correspond aux attentes. Voici des étapes spécifiques et pratiques pour vérifier :

I. Visualisation-en temps réel du décalage de synchronisation (la méthode la plus intuitive)

Exécutez le service PTP sur le capteur d'horloge esclave et observez les journaux. Il s’agit de la référence en matière de jugement de la précision de la synchronisation.

Exécutez la commande :

bash sudo ptp4l -i eth0 -m -q

Remarque : eth0 doit être remplacé par le nom réel de l'interface réseau connectée au réseau PTP ; -m indique l'impression de journaux détaillés et -q réduit les informations redondantes.

Critères de jugement

Observez le champ de décalage dans le journal de sortie :

Synchronisation normale : la valeur de décalage est stable entre ±1 et 10 microsecondes (µs), avec une fluctuation minimale.

Anomalie de synchronisation : les valeurs de décalage sont de l'ordre de la milliseconde (ms) ou fluctuent considérablement (par exemple, passant soudainement de +50µs à -200 µs).

Non synchronisé : des états DEFAILLANTS fréquents apparaissent dans les journaux ou la meilleure horloge maître ne peut pas être sélectionnée.

II. Vérifier le statut du rôle maître-esclave

Assurez-vous que les deux capteurs ont correctement établi une relation maître-esclave pour éviter les conflits "double-maître" ou les commutations fréquentes.

Voir les résultats des élections BMCA

Recherchez l'expression « meilleure horloge maîtresse sélectionnée » dans les journaux.

Normal : le journal de l'horloge esclave montre qu'il a reconnu l'horloge principale et est entré dans l'état SLAVE.

Anormal : Les deux capteurs s'affichent comme MAÎTRE, indiquant une configuration de priorité incorrecte ou une interruption de communication.

Vérifier les paramètres de priorité

Confirmez que la valeur de priorité1 du capteur maître est inférieure à celle du capteur esclave (par exemple, maître réglé sur 128, esclave réglé sur 130), en vous assurant que le rôle est fixe et ne change pas arbitrairement en raison de la gigue du réseau.

III. Vérifiez si l'horodatage matériel est efficace

Si le décalage est de l'ordre de la milliseconde, c'est généralement parce que les horodatages matériels ne sont pas activés, ce qui entraîne une précision insuffisante.

Exécutez la commande :

`bash ethtool -T eth0`

Critères de jugement : la sortie doit contenir `SOF_TIMESTAMPING_TX_HARDWARE` et `SOF_TIMESTAMPING_RX_HARDWARE`.

Si seul « LOGICIEL » est présent, cela indique que des horodatages logiciels sont utilisés et que la précision ne peut pas répondre aux exigences d'une comparaison de haute -double capteur-de précision. La prise en charge du pilote ou du matériel doit être vérifiée.

IV. Surveillance de la stabilité à long-terme

La normalité à court-terme ne garantit pas la stabilité à long-terme. Des tests de résistance à court-terme sont recommandés.

Taux de dérive record

Exécutez `phc2sys` pour synchroniser l'horloge matérielle PTP avec l'horloge système et observer le décalage maximum sur 24 heures.

Normal : la dérive à long-terme est contrôlée en 1 microseconde, sans écart cumulé.

Anormal : le décalage augmente linéairement au fil du temps, indiquant que la compensation de fréquence de l'oscillateur à cristal n'est pas efficace ou qu'il existe une latence asymétrique du réseau.

Observez la perte de paquets. Vérifiez les journaux PTP pour les alarmes de délai d'expiration peer_delay ou de délai de synchronisation. Des occurrences occasionnelles sont tolérables, mais des occurrences fréquentes nécessitent de vérifier la qualité du câble réseau, la charge du commutateur ou les paramètres du pare-feu (assurez-vous que les ports UDP 319/320 sont ouverts).

V. Tableau de dépannage commun