El núcleo de comprobar si la sincronización PTP del sensor dual-es normal es verificar si el desplazamiento de tiempo es estable dentro del rango de microsegundos y si el estado maestro-esclavo coincide con las expectativas. A continuación se detallan pasos específicos y prácticos para verificar:
I. Visualización en tiempo real-de la compensación de sincronización (el método más intuitivo)
Ejecute el servicio PTP en el sensor de reloj esclavo y observe los registros. Este es el estándar de oro para juzgar la precisión de la sincronización.
Ejecute el comando:
bash sudo ptp4l -i eth0 -m -q
Nota: eth0 debe reemplazarse con el nombre de la interfaz de red real conectada a la red PTP; -m indica la impresión de registros detallados y -q reduce la información redundante.
Criterios de juicio
Observe el campo de compensación en el registro de salida:
Sincronización normal: el valor de compensación es estable dentro de ±1~10 microsegundos (μs), con una fluctuación mínima.
Anomalía de sincronización: los valores de compensación están en el rango de milisegundos (ms) o fluctúan drásticamente (por ejemplo, cambian repentinamente de +50μs a -200μs).
No sincronizado: aparecen estados FALLOS frecuentes en los registros o no se puede seleccionar el mejor reloj maestro.
II. Verificar el estado del rol Maestro-Esclavo
Asegúrese de que los dos sensores hayan establecido correctamente una relación maestro-esclavo para evitar conflictos de "doble-maestro" o cambios frecuentes.
Ver los resultados de las elecciones de BMCA
Busque la frase "mejor reloj maestro seleccionado" en los registros.
Normal: el registro del reloj esclavo muestra que reconoció el reloj maestro y entró en estado ESCLAVO.
Anormal: Ambos sensores se muestran como MAESTRO, indicando una configuración de prioridad incorrecta o interrupción de la comunicación.
Verifique la configuración de prioridad
Confirme que el valor de prioridad1 del sensor maestro sea menor que el del sensor esclavo (por ejemplo, maestro configurado en 128, esclavo configurado en 130), asegurando que la función sea fija y no cambie arbitrariamente debido a la fluctuación de la red.
III. Compruebe si la marca de tiempo del hardware es efectiva
Si el desplazamiento está en el rango de milisegundos, generalmente se debe a que las marcas de tiempo del hardware no están habilitadas, lo que resulta en una precisión insuficiente.
Ejecute el comando:
`bash ethtool -T eth0`
Criterios de juicio: la salida debe contener `SOF_TIMESTAMPING_TX_HARDWARE` y `SOF_TIMESTAMPING_RX_HARDWARE`.
Si solo está presente "SOFTWARE", indica que se están utilizando marcas de tiempo de software y que la precisión no puede cumplir con los requisitos para la comparación de sensores duales- de alta-precisión. Es necesario comprobar la compatibilidad con controladores o hardware.
IV. Monitoreo de estabilidad a largo plazo-
La normalidad-a corto plazo no garantiza la estabilidad a largo plazo-. Se recomiendan pruebas de estrés-a corto plazo.
Récord de tasa de deriva
Ejecute `phc2sys` para sincronizar el reloj del hardware PTP con el reloj del sistema y observe el desplazamiento máximo durante 24 horas.
Normal: la deriva-a largo plazo se controla en 1 microsegundo, sin desviación acumulativa.
Anormal: el desplazamiento aumenta linealmente con el tiempo, lo que indica que la compensación de frecuencia del oscilador de cristal no es efectiva o que hay una latencia asimétrica en la red.
Observe la pérdida de paquetes. Verifique los registros de PTP para ver si hay alarmas de tiempo de espera de peer_delay o de tiempo de espera de sincronización. Los sucesos ocasionales son tolerables, pero los sucesos frecuentes requieren verificar la calidad del cable de red, la carga del conmutador o la configuración del firewall (asegúrese de que los puertos UDP 319/320 estén abiertos).
V. Tabla de solución de problemas comunes
|
Fenómeno |
Posible causa |
Sugerencia de solución |
|
Compensación en milisegundos |
Marca de tiempo de hardware no habilitada |
Verifique ethtool -T, instale el controlador dedicado y habilite la marca de tiempo del hardware. |
|
Cambio frecuente de maestro-esclavo |
La configuración de prioridad es la misma o similar |
Aumente la diferencia en Prioridad1 entre maestro y esclavo (por ejemplo, 128 frente a 130). |
|
Completamente incapaz de sincronizar |
Indisponibilidad de red o bloqueo de firewall |
Haga una prueba de conectividad, deshabilite el firewall o permita los puertos UDP 319/320. |
|
Grandes fluctuaciones de compensación |
Jitter de red o carga alta |
Aísle el tráfico PTP, habilite QoS en el conmutador para priorizar los paquetes PTP. |

