[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