[ntp:questions] Re: NMEA refclock - PPS not working

R Jenkins 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 2.6.16.9 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 
> jitter
> ==============================================================================
> xGPS_NMEA(0)     .GPS.            1 l   39   64  377    0.000  -263.67 
> 145.858
> +gate.jrw.intra  130.159.196.118  3 u    -   16  377    0.212  252.072 
> 19.115
> *Time2.Stupi.SE  .PPS.            1 u   46   64  377   52.478  191.170 
> 85.622
> +arg.cmm.ki.si   131.188.3.223    2 u   45   64  377   61.012   49.949 
> 105.216
>
> ntptime
> 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 
> 3200.
>
> 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 
motherboard/chipset/software etc.

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 
servers.
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 
correction).

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?

Robert Jenkins.





More information about the questions mailing list