For å bekrefte vellykket master-slaverollelåsing krever en kombinasjon av tre dimensjoner: konfigurasjonsparameterbekreftelse, sanntidsloggovervåking og stresstesting. Dette sikrer at rollen ikke bytter under både normale og unormale nettverksforhold:
I. Verifikasjon av konfigurasjonsfilparameter
Sjekk `/etc/linuxptp/ptp4l.conf` konfigurasjonsfilen på begge sensorene for å bekrefte at nøkkellåseparametere er aktive:
Mesterklokke
"prioritet1" skal være en lav verdi (f.eks. 128).
`masterOnly 1`: Dette er kjerneparameteren for å låse rollen, noe som indikerer at noden er tvunget til å bli masterklokke og nekter å delta i BMCA-valget for å bli en slaveklokke.
Slave klokke
`prioritet1` bør være en høy verdi (f.eks. 130), og sikrer at dens prioritet er lavere enn hovedklokken.
`masterOnly 0` (standard): Lar den synkroniseres som en slaveklokke.
II. Loggstatusovervåking i sann-tid
Etter å ha startet ptp4l-tjenesten på nytt, kjør `sudo ptp4l -i eth0 -m -q` for å observere sanntidsloggene-:
Fast rollevisning: Hovedenhetsloggen skal kontinuerlig vise "port 1: MASTER".
Slaveenhetsloggen skal kontinuerlig vise "port 1: SLAVE".
Ingen valgalarmer: Loggene skal ikke inneholde poster som indikerer BMCA-gjen-valg, for eksempel "beste hovedklokke endret" eller "valgt beste hovedklokke".
Hvis FEIL-tilstanden vises og deretter raskt går tilbake til den opprinnelige rollen, fungerer låsemekanismen; hvis rollene byttes etter gjenoppretting, har låsingen mislyktes.
III. Nettverksfrakobling og gjenoppkobling stresstest (ultimate verifikasjon)
Simuler et scenario for nettverksavbrudd for å verifisere robustheten til rollelåsing:
Drift: Koble midlertidig fra slaveklokkenettverkskabelen eller deaktiver nettverkskortgrensesnittet, vent ca. 10-20 sekunder, og gjenopprett deretter tilkoblingen.
Vurderingskriterier:
Vellykket låsing: Hovedklokken forblir i MASTER-tilstand under nettverksavbrudd (eller går inn i LYTTING, men degraderes ikke til SLAVE); etter nettverksgjenoppretting synkroniseres slaveklokken raskt på nytt og stabiliserer seg i SLAVE-tilstand, uten rollebytte hele veien.
Mislykket låsing: Under nettverksavbrudd bedømmer masterklokken feilaktig hele nettverket som masterløst på grunn av mangel på pakker, og bytter automatisk til SLAVE eller går inn i en ubestemt tilstand; etter gjenoppretting, velges de to klokkene om-, noe som kan føre til omvendt rolle eller langvarig svingning.
IV. Verifikasjon av systemklokkekilde
Kjør `chronyc sources -v` eller `phc2sys` på slaveenheten for å sjekke statusen:
Bekreft at systemklokken bare følger den spesifiserte PTP-maskinvareklokken (f.eks. /dev/ptp0), og forskyvningen er stabil i mikrosekundområdet uten betydelige hopp, noe som indirekte beviser stabiliteten til master-slaveforholdet.
