[LinuxPPS] kernel 2.6.32 - ntpd-4.2.6 linuxpps experiences
Hal V. Engel
hvengel at astound.net
Mon Dec 14 03:18:22 CET 2009
On Sunday 13 December 2009 03:34:30 pm clemens at dwf.com wrote:
> > Hello all,
> >
> > Having been an early LinuxPPS adaptor, it has been quiet for a while from
> > this side.
> >
> > Today I decided to upgrade my kernel from 2.6.27.6 to 2.6.32 and had to
> > figure out 'how on earth did I manage(d) to get LinuxPPS running after a
> > kernel upgrade?'.
> >
> > After downloading kernel 2.6.32, I applied the ntp-pps-v2.6.32-rc8.diff
> > patch, compiled the kernel, and rebooted.
>
> <snip>
>
> > I discovered that the NANO option in timex.h is inserted as of kernel
> > 2.6.30. However, for whatever reason with this timex.h ntpd failed to
> > compile. So I used the 'old' timex.h nano patch from the mid 2008s
> > instead, which worked.
>
> Yes the NANO defines FOR THE KERNEL are in the kernel version of timex.h
> but these are STA_NANO and ADJ_NANO, ntpd needs MOD_NANO, and this is
> *not* in the kernel version of this timex.h .
>
> > I used ntpd-4.2.5-p113 and after starting the freshly compiled ntpd I
> > could not find my Oncore (driver 30) in the peers list (ntpq -p).
I had the same issue with an older version of ntp. It appears that recent
versions of LinuxPPS/kernel requires fairly recent versions of ntp to work
with the Oncore.
>
> Not sure why, but that version is over a year old.
> The ONCORE driver really hasnt had any changes.
>
> > Having more things to do today than being busy with LinuxPPS I downloaded
> > the latest stable ntp version (4.2.6) and compiled it.
4.2.6 was apparently just released in the last few days.
> >
> > With this version GPS_ONCORE(0) appeared in the peers list, but no
> > synchronization could be detected.
I have found that this version of kernel/linuxpps and ntp version
dev-4.2.5_p250-RC (which is probably the same code as 4.2.6) takes a long time
to sync with the Oncore. I don't know why but on my machine it takes an hour
or two to sync even with --panicgate set. In fact --panicgate does not seem
to have any affect on these newer versions of ntp.
With the older versions of the kernel/linuxpps/ntp it would sync in just a few
minutes and --panicgate would cause a time jump to within perhaps 50
microseconds in about 1 minute.
At first I thought that it was not going to sync since I was used to this
happening very quickly but I decided to wait to see if it would eventually
sync and it did.
$ ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*GPS_ONCORE(0) .GPS. 0 l 3 16 377 0.000 0.001 0.000
$ ntptime
ntp_gettime() returns code 0 (OK)
time cecffbef.7a99b6c8 Sun, Dec 13 2009 15:49:03.478, (.478908182),
maximum error 2733 us, estimated error 0 us
ntp_adjtime() returns code 0 (OK)
modes 0x0 (),
offset 1.223 us, frequency -38.604 ppm, interval 1 s,
maximum error 2733 us, estimated error 0 us,
status 0x2001 (PLL,NANO),
time constant 4, precision 0.001 us, tolerance 500 ppm,
$ ntpdc -c kern
pll offset: 2.089e-06 s
pll frequency: -38.595 ppm
maximum error: 0.000234 s
estimated error: 0 s
status: 2001 pll nano
pll time constant: 4
precision: 1e-09 s
frequency tolerance: 500 ppm
I just tested with 4.2.6 and it did sync but it took about 1 hour and the
clock was very screwed up for about the first 15 minutes with about a -34
second offset. It then adjusted the time to a near zero offset but it set the
frequency to -500.000 ppm which is clearly wrong. Then about 10 minutes later
the clock synced for a short time with an offset of about 2.6 milliseconds and
the frequency was set to -40.425 ppm which is close to the -38.6 ppm that I
would expect when things have stabilized (at the current room temperature).
At that point jitter was still very high (0.135) and the time was still
drifting (IE. the offset was increasing). It then fell out of sync after about
5 minutes and finally synced again about 1 hour after the restart. At that
point it appeared to operate normally and is now staying in sync.
>
> Again, I dont understand this.
> I have been running with the 2.6.32 since it was released, and with various
> of the prerelease versions of ntp with no problems.
>
> > Knowing that I had PPS stamps, I tried the ATOM driver (driver 22), and
> > used a preferred time source from my local network. After a while
> > ntpd-4.2.6 synced to my PPS signal ... WITH the ppsfreq, and ppstime bits
> > set (!).
> >
> > remco at helium > ntpdc -c kern
> > pll offset: -6.82e-07 s
> > pll frequency: 17.942 ppm
> > maximum error: 0.007736 s
> > estimated error: 0 s
> > status: 2007 pll ppsfreq ppstime nano
> > pll time constant: 4
> > precision: 1e-09 s
> > frequency tolerance: 500 ppm
> >
> > remco at helium > ntpq -p
> > remote refid st t when poll reach delay offset
> > jitter
> > =========================================================================
> >===== oPPS(0) .PPS. 0 l 13 16 377 0.000
> > -0.001 0.002 *freebsd .GPS. 1 u 63 64 377
> > 0.211 0.000 0.012 +lithium .DCFa. 1 u 42 64
> > 377 0.157 -0.655 0.110 +ptbtime1.ptb.de .PTB. 1 u 46
> > 64 377 49.874 0.244 0.198
> >
> > The stability seems to be better than with the 2001 status (pll , nano)
> > but I wonder why the Oncore driver fails to work.
>
> Beats me, you are using the current kernel and a current version of ntpd,
> which is the same as Im running. Everything should 'just work'.
>
Again on my machine this setup takes a long to to sync. Retry with the Oncore
driver and let it run for a while and it should sync eventually. But it may
take several hours. This appears to be a regression in ntp.
There are bug reports of a similar nature for newer versions of ntp on the ntp
bugzilla:
https://support.ntp.org/bugs/show_bug.cgi?id=1351
https://support.ntp.org/bugs/show_bug.cgi?id=1307
Hal
More information about the LinuxPPS
mailing list