[ntp:questions] Time synchronization

David Mills mills at udel.edu
Fri Feb 6 19:12:33 UTC 2009


Dahal,

I've never seen a properly configured GPS/PPS configuration behave as 
badly as you report. See pogo.udel.edu as example. It rarely strays more 
than a couple of microseconds.

First, as mentioned several times, ntpdc lies through its teeth. Some of 
the billboard items reflect data that have vanished ten years ago; 
others mesrepresent the facts. Personally, as stated very many time, I 
prefer it (and ntpdate) to go away. The ntpq program has been carefully 
maintained to say the facts and ntpdate has been replaced by sntp, 
either from the NTP distribution or from NIST or other places.

Second, your billbards, such as they are, show the kernel is not 
disciplining the system time, in spite of the claimed reference clock 
identifier says PPS. In addition, the claimed precision is -7 (1/128 = 
about 4 ms), which is consistent with the statistics you show. I don't 
know in detail what the SHM driver is doing, but it is not doing a good 
job.

Third, the data reported is not from ntpd, but another daemon called 
gpsd. Apparently it doesn'tt like the PPS signal. I don't know what 
grooming algorithm it uses, but both the kernel and atom driver use a 
trimmed-mean median filter, which is a rather heave dose of signal 
processing that probably would not be the first inspiration of folks who 
have not studied the detailed statistics.

Dave

Dahal Runa wrote:

>We are using a highly accurate (GPS RT3000) and we are synchronizing our
>system's time using the NTP computer. The time synchronization is pretty
>accurate But we are receiving high offset and jitter values in moxa(UC-7112
>plus) therefore we are not able to replace the moxa with the NTP.By using ntpq
>-p the offset and jitter values obtained in NTP computer is:
>
>     remote           refid      st t when poll reach   delay   offset  jitter
>==============================================================================
>+SHM(0)          .NMEA.           0 l    2   16    7    0.000   -0.829   0.479
>*SHM(1)          .PPS.            0 l    -   16    7    0.000   -0.899   0.158
>
>and as for the MOXA board using ntpq -p we obtained the following offset and
>jitter values:
>
>     remote           refid      st t when poll reach   delay   offset  jitter
>==============================================================================
>*SHM(0)          .NMEA.           0 l    -   16    3    0.000   -0.058   0.416
> SHM(1)          .PPS.            0 l    -   16    3    0.000   -0.648   0.294
>
>the following messages were received on the moxa board on running the GPSD in
>debug mode:
>
>gpsd: Packet discard of 35, chars remaining is 0 = 
>gpsd: <= GPS: $GPZDA,220649.000,05,02,2009,,*51
>gpsd: pps-detect (DCD) on /dev/ttyM0 changed to 0
>gpsd: PPS pulse rejected. No fix.
>gpsd: pps-detect (DCD) on /dev/ttyM0 changed to 1
>gpsd: PPS pulse rejected. No fix.
>gpsd: polling 4
>gpsd: Read 35 chars to buffer offset 0 (total 35):
>244302e3030302c30352c30322c323030392c2c2a35390d0a
>gpsd: Packet discard of 35, chars remaining is 0 = 
>gpsd: <= GPS: $GPZDA,220650.000,05,02,2009,,*59
>gpsd: pps-detect (DCD) on /dev/ttyM0 changed to 0
>gpsd: PPS pulse rejected. No fix.
>gpsd: pps-detect (DCD) on /dev/ttyM0 changed to 1
>gpsd: PPS pulse rejected. No fix.
>gpsd: polling 4
>gpsd: Read 35 chars to buffer offset 0 (total 35):
>2447505a44412c3232303635312e3030302c30352c30322c323030392c2c2a35380d0a
>gpsd: Packet type 1 accepted 35 =
>2447505a44412c3232303635312e3030302c30352c30322c323030392c2c2a35380d0a7505a44412c3232303635302e3030302c30352c30322c323030392c2c2a35390d0a
>gpsd: Packet type 1 accepted 35 = 2447505a44412c3232303635
>gpsd: Packet discard of 35, chars remaining is 0 = 
>gpsd: <= GPS: $GPZDA,220651.000,05,02,2009,,*58
>gpsd: pps-detect (DCD) on /dev/ttyM0 changed to 0
>gpsd: PPS pulse rejected. No fix.
>
>on running the ntpdc query program we got the following result:
>
>ntpdc> kerninfo
>pll offset:           -0.002838 s
>pll frequency:        35.740 ppm
>maximum error:        0.029256 s
>estimated error:      0.015308 s
>status:               0001  pll
>pll time constant:    0
>precision:            1e-06 s
>frequency tolerance:  512 ppm
>pps frequency:        0.000 ppm
>pps stability:        512.000 ppm
>pps jitter:           0.0002 s
>calibration interval: 4 s
>calibration cycles:   0
>jitter exceeded:      0
>stability exceeded:   0
>calibration errors:   0
>
>
>
>ntpdc> loopinfo
>***Warning changing to older implementation
>offset:               -0.003678 s
>frequency:            40.670 ppm
>poll adjust:          30
>watchdog timer:       6 s
>
>
>ntpdc> sysinfo
>system peer:          SHM(1)
>system peer mode:     client
>leap indicator:       00
>stratum:              1
>precision:            -7
>root distance:        0.00000 s
>root dispersion:      0.02675 s
>reference ID:         [PPS]
>reference time:       cd35cdf3.c3448062  Fri, Feb  6 2009  4:43:31.762
>system flags:         auth monitor ntp kernel stats 
>jitter:               0.014694 s
>stability:            1.008 ppm
>broadcastdelay:       0.003998 s
>authdelay:            0.000000 s
>
>
>ntpdc> sysstats
>time since restart:     945
>time since reset:       945
>packets received:       262
>packets processed:      0
>current version:        0
>previous version:       243
>bad version:            0
>access denied:          0
>bad length or format:   0
>bad authentication:     0
>rate exceeded:          0
>
>On moxa we are using the firmware version V1.0. I would like to know whether
>such kind of output can be expected for such kind of hardware? Is it possible
>to use it in place of NTP Computer?
>
>
>
>_______________________________________________
>questions mailing list
>questions at lists.ntp.org
>https://lists.ntp.org/mailman/listinfo/questions
>  
>




More information about the questions mailing list