[ntp:questions] Re: NMEA refclock - PPS not working
not at pub.lished
Mon May 15 08:06:29 UTC 2006
"R Jenkins" <not at pub.lished> wrote in message
news:4467a5ca$0$546$ed2619ec at ptn-nntp-reader01.plus.net...
> Hi again..
> My previous problem with ntpq timing out was solved by using the latest
> dev release of the NTP source, it appears to be a bug in the (old) version
> used by Redhat / Centos 4.
> I can now monitor ntpd, but it's still not locking to the PPS input.
> The relevent bit of ntp.conf is:
> # NMEA Clock using Garmin GPS
> server 127.127.20.0 mode 1 version 4 prefer
> fudge 127.127.20.0 refid GPS flag3 1 time1 0.042 stratum 1
> (plus three other servers).
> Kernel 126.96.36.199 with ppskit-lite patch.
> These are the results after about half an hour:
> ntpq -c peers
> remote refid st t when poll reach delay offset
> xGPS_NMEA(0) .GPS. 1 l 39 64 377 0.000 -263.67
> +gate.jrw.intra 188.8.131.52 3 u - 16 377 0.212 252.072
> *Time2.Stupi.SE .PPS. 1 u 46 64 377 52.478 191.170
> +arg.cmm.ki.si 184.108.40.206 2 u 45 64 377 61.012 49.949
> ntp_gettime() returns code 0 (OK)
> time c812205b.41762000 Sun, May 14 2006 22:32:11.255, (.255709),
> maximum error 719516 us, estimated error 44711 us
> ntp_adjtime() returns code 0 (OK)
> modes 0x0 (),
> offset 19886.000 us, frequency -390.653 ppm, interval 4 s,
> maximum error 719516 us, estimated error 44711 us,
> status 0x1 (PLL),
> time constant 2, precision 1.000 us, tolerance 496 ppm,
> pps frequency 0.000 ppm, stability 0.000 ppm, jitter 0.000 us,
> intervals 0, jitter exceeded 0, stability exceeded 0, errors 0.
> This was after initially running ntpdate against the stratum 1 server &
> deleting the drift file.
> The ntptime 'frequency 390.653 ppm' entry is slowly oscillating. It's been
> to both extremes +/- 495.9ppm.
> Eventually the offset drifts to the point where it does a jump or step.
> The jitter on the first server line seems odd to me, it's a local machine
> on a gigabit link with next to no other network traffic at the moment.
> I'm beginning to think there is either something wierd with the board or
> BIOS - it's a Gigabyte K8N Ultra-9 with an nforce4 chipset & Athlon 64
> Alternately, is there another PPS mode that runs without the kernel patch?
> That should still be better than using internet servers only.
> Robert Jenkins.
I've just done another test to try and determine if the machine is losing
time due to the 'Hz = 250' or any other problems with the
I started ntpd after deleting the drift file and running ntpdate against my
other timeserver (which is quite stable).
On this machine, that server is configured with minpoll 4 maxpoll 4 iburst
so it is updating frequently.
If the one I'm working on really has bad clock dift, I beleieve it should
show up as the offset to the other server changing quite rapidly before ntpd
gets 'in lock' and sets up the calculated drift.
I gave it a minute to start up and get responses from all three configures
I then left it just over 2 minues and checked the offsets again.
(ntptime was still showing 0.000 ppm, so presumably still no drift
If it was really drifting badly enough to hit the 496pps limit, the time
offset should have changed by around 60mS.
It was actually just 0.340 mS different, a drift of around 3 ppm.
(The other server is presently running with a drift of 6ppm according to
ntptime, so this does not seem unreasonable).
Any thoughts on this?
More information about the questions