Creé un proyecto ( https://github.com/kshetline/aw-clock ) que, entre muchas otras cosas, detecta la sincronización de tiempo GPS con PPS al examinar la salida del comando ntpq . Lo que espero es una salida que se ve así:
pi@clock:~ $ ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== 0.debian.pool.n .POOL. 16 p - 64 0 0.000 +0.000 0.001 1.debian.pool.n .POOL. 16 p - 64 0 0.000 +0.000 0.001 2.debian.pool.n .POOL. 16 p - 64 0 0.000 +0.000 0.001 3.debian.pool.n .POOL. 16 p - 64 0 0.000 +0.000 0.001 *SHM(2) .PPS. 0 l 9 64 377 0.000 -0.007 0.001 xSHM(0) .GPS. 0 l 10 64 377 0.000 -586.75 58.377 -eterna.binary.n 128.138.140.44 2 u 79 128 377 62.565 +2.244 4.420 +t2.time.bf1.yah 98.139.133.62 2 u 53 64 377 28.750 +3.667 10.354 -65-100-46-164.d .SOCK. 1 u 3 64 377 88.300 +3.213 9.568 +time-ewr.0xt.ca 17.253.14.251 2 u 11 64 377 19.489 +2.813 12.572Para mis propios fines, verificar la línea con SHM y PPS con la siguiente expresión regular me ha funcionado bien:
/^\*SHM\b.+\.PPS\.\s+0\s+l\s+.+?\s([-+]?[.\d]+)\s+[.\d]+\s*$/
Uno de los usuarios de mi proyecto dice que tiene sincronización GPS, pero mi código no lo detecta. No está seguro acerca de la sincronización PPS. Su salida de ntpq se ve así:
pi@raspberrypi:~ $ ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== 0.debian.pool.n .POOL. 16 p - 64 0 0.000 +0.000 0.001 oPPS(0) .PPS. 0 l 7 16 377 0.000 -290.00 0.321 *SHM(0) .GPS. 1 l 4 16 377 0.000 +4.782 4.952 SHM(2) .SHM2. 0 l - 16 0 0.000 +0.000 0.000 time.skylineser 130.207.244.240 2 u 50 64 1 37.196 -285.61 0.322 +ntp1.ring-u.net 130.207.244.240 2 u 49 64 1 28.878 -280.98 1.622 +50-205-244-108- 50.205.244.27 2 u 47 64 1 27.833 -287.90 3.220 sonic.boom.net 128.9.176.30 2 u 57 64 1 71.871 -284.30 0.001 No puedo encontrar suficiente documentación para que ntpq explique cómo esta salida funciona lo suficientemente bien como para entender si esta salida indica una sincronización PPS adecuada, solo de una manera diferente a la que me aparece, o si esto indica un problema.
La salida del usuario es en realidad la misma que la suya, solo que sin formato roto.
Parece que el desplazamiento de PPS es bastante grande, así que me pregunto si tienen todo configurado correctamente. También tienen una entrada SHM(2) que parece no estar haciendo nada. Me pregunto si la configuración de memoria compartida es correcta. Mi lista de fuentes de entrada como;
GPS NMEA: xSHM(0) .GPS. 0 l 3 16 377 0.000 -116.89 24.632
PPS: *SHM(1) .PPS. 0 l 6 16 377 0.000 -0.014 0.045
Los documentos para ntpq se pueden encontrar aquí . Y la parte que explica los indicadores de estado se puede encontrar aquí .
Extracto de los documentos;
discarded as not valid x discarded by intersection algorithm . discarded by table overflow (not used) - discarded by the cluster algorithm + included by the combine algorithm # backup (more than tos maxclock sources) * system peer o PPS peer (when the prefer peer is valid)
Sería curioso ver allí ntp.conf real. Me pregunto si tienen una configuración extraña o específica. De un vistazo rápido, diría que en realidad uso el GPS/NMEA como el par del sistema en lugar del PPS . Ejecuto varios servidores S1 de producción y no he tenido una situación en la que el PPS esté marcado con el o
También supongo que cuando lo enviaron a través de esa salida, el servidor no había estado funcionando por mucho tiempo (o al menos no tenía mucha conectividad) ya que la accesibilidad de los servidores IP remotos es solo 2 y, dado que hay encuestas cada 64 segundos, diría no son accesibles o no les gustan las encuestas de alta frecuencia.
Idealmente, deben dejarlo funcionando durante un tiempo (al menos hasta que todo tenga un alcance de 377) y luego volver a mirar. Si tienen la suite ntpq completa, obtenga el resultado de ntpq -pcrv y proporcionará detalles más profundos.