Die Überprüfung einer erfolgreichen Master-{0}}Slave-Rollensperrung erfordert eine Kombination aus drei Dimensionen: Überprüfung der Konfigurationsparameter, Protokollüberwachung in Echtzeit und Stresstests. Dadurch wird sichergestellt, dass die Rolle sowohl unter normalen als auch unter abnormalen Netzwerkbedingungen nicht wechselt:
I. Überprüfung der Konfigurationsdateiparameter
Überprüfen Sie die Konfigurationsdatei „/etc/linuxptp/ptp4l.conf“ auf beiden Sensoren, um zu bestätigen, dass die Tastensperrparameter wirksam sind:
Hauptuhr
„Priorität1“ sollte ein niedriger Wert sein (z. B. 128).
„masterOnly 1“: Dies ist der Kernparameter zum Sperren der Rolle, der angibt, dass der Knoten gezwungen ist, zur Master-Uhr zu werden, und sich weigert, an der BMCA-Wahl teilzunehmen, um eine Slave-Uhr zu werden.
Nebenuhr
„Priorität1“ sollte ein hoher Wert sein (z. B. 130), um sicherzustellen, dass seine Priorität niedriger ist als die des Haupttakts.
„masterOnly 0“ (Standard): Ermöglicht die Synchronisierung als Slave-Uhr.
II. Überwachung des Protokollstatus in Echtzeit
Führen Sie nach dem Neustart des ptp4l-Dienstes „sudo ptp4l -i eth0 -m -q“ aus, um die Echtzeitprotokolle zu beobachten:
Feste Rollenanzeige: Im Master-Geräteprotokoll sollte ständig „Port 1: MASTER“ angezeigt werden.
Im Protokoll des Slave-Geräts sollte ständig „Port 1: SLAVE“ angezeigt werden.
Keine Wahlalarme: Die Protokolle sollten keine Datensätze enthalten, die auf eine Wiederwahl der BMCA hinweisen, wie z. B. „beste Hauptuhr geändert“ oder „beste Hauptuhr ausgewählt“.
Wenn der Zustand FAULTY auftritt und dann schnell in die ursprüngliche Rolle zurückkehrt, funktioniert der Sperrmechanismus; Wenn die Rollen nach der Wiederherstellung vertauscht werden, ist die Sperrung fehlgeschlagen.
III. Belastungstest für Netzwerktrennung und -wiederverbindung (ultimative Überprüfung)
Simulieren Sie ein Netzwerkausfallszenario, um die Robustheit der Rollensperre zu überprüfen:
Vorgehensweise: Trennen Sie vorübergehend das Netzwerkkabel der Nebenuhr oder deaktivieren Sie die Netzwerkkartenschnittstelle, warten Sie etwa 10 bis 20 Sekunden und stellen Sie dann die Verbindung wieder her.
Beurteilungskriterien:
Erfolgreiche Sperrung: Die Hauptuhr bleibt während einer Netzwerkunterbrechung im MASTER-Zustand (oder wechselt in den LISTENING-Zustand, wird aber nicht auf SLAVE herabgestuft); Nach der Wiederherstellung des Netzwerks synchronisiert sich die Slave-Uhr schnell neu und stabilisiert sich im SLAVE-Zustand, ohne dass die Rollen ständig gewechselt werden.
Fehlgeschlagene Sperrung: Während einer Netzwerkunterbrechung beurteilt die Hauptuhr aufgrund fehlender Pakete fälschlicherweise das gesamte Netzwerk als „masterlos“ und schaltet automatisch auf SLAVE um oder geht in einen unbestimmten Zustand über. Nach der Wiederherstellung werden die beiden Uhren wiedergewählt, was zu einem Rollentausch oder einer längeren Oszillation führen kann.
IV. Überprüfung der Systemtaktquelle
Führen Sie „chronyc resources -v“ oder „phc2sys“ auf dem Slave-Gerät aus, um den Status zu überprüfen:
Bestätigen Sie, dass die Systemuhr nur der angegebenen PTP-Hardwareuhr (z. B. /dev/ptp0) folgt und der Offset im Mikrosekundenbereich ohne nennenswerte Sprünge stabil ist, was indirekt die Stabilität der Master--Slave-Beziehung beweist.
