[LinuxPPS] cross posting [time-nuts] NTP API on Linux 2.6.26

[Hal V. Engel]

On Saturday 10 January 2009 11:41:08 Udo van den Heuvel wrote:
> Michael Meier wrote:
> > You will also need to tell configure to use librt (./configure
> > LIBS="-lrt") - without librt, ntpd will resort to using gettimeofday for
> > getting time from the kernel, and that function only returns
> > microseconds because it is defined that way.
>
> How is this on Fedora?
> My ntpd shows the "nano" thing but do you imply that the accuracy 'under
> water' could be different?
>
> Udo

I just tested ntp configured with LIBS=-lrt".  This is on a gentoo x86_64 
system using glibc 2.8 and an ntp snap shot that is about a month old.  I did 
not have much luck with ntp built this way since it would not sync up 
correctly.  It set my clock about 38 seconds fast and never changed the 
frequency to try to sync the clock to UTC.  Here is what I was seeing about 20 
minutes after ntpd was started:

# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*GPS_ONCORE(0)   .GPS.            0 l    5   16  377    0.000  -37999.   0.035

# ntptime
ntp_gettime() returns code 0 (OK)
  time cd137e25.947b02a0  Sat, Jan 10 2009 12:05:57.580, (.580002806),
  maximum error 8294508 us, estimated error 2 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset -0.426 us, frequency -39.298 ppm, interval 1 s,
  maximum error 8294508 us, estimated error 2 us,
  status 0x2001 (PLL,NANO),
  time constant 4, precision 0.001 us, tolerance 500 ppm,

As you can see ntpq -p shows the 38 second offset.  I have a radio controlled 
(WWVB) clock in the same room and it was apparent the the computer clock was 
off by about 38 seconds compared to it.  So the ntpq -p query was showing the 
correct result  The interesting thing is that ntptime shows an offset of < 1us 
so ntptime is clearly wrong.  

When I reverted to a version of ntp built without configuring with LIBS="-lrt" 
it synced right up and within a few minutes of restarting ntpd my offset using 
both nptq and ntptime was <50us and they agreed with each other.  In addition 
my radio controlled wall clock now agrees with the time on my computer.   Here 
is what I am seeing without librt linked in after ntpd has been running about 
40 minutes:

# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*GPS_ONCORE(0)   .GPS.            0 l    5   16  377    0.000   -0.019   0.002

# ntptime
ntp_gettime() returns code 0 (OK)
  time cd1386db.88a9ffe4  Sat, Jan 10 2009 12:43:07.533, (.533844787),
  maximum error 5753 us, estimated error 0 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset -18.435 us, frequency -39.290 ppm, interval 1 s,
  maximum error 5753 us, estimated error 0 us,
  status 0x2001 (PLL,NANO),
  time constant 4, precision 0.001 us, tolerance 500 ppm,

Librt is supplied by glibc so there are apparently other issues with the time 
stuff in glibc that need to be resolved besides the stuff that we already have 
patches for.  Is the above issue a 64bit issue?  Or is it a problem with the 
version of glibc I am running?  

I was the one who opened

 http://sources.redhat.com/bugzilla/show_bug.cgi?id=9690

Remco has pointed out that this bug and the related gentoo bug have generated 
some interest on the time-nuts email list.  I was notified that the gentoo 
toolchain team had been added to the CC list for this bug and it appears that 
the bug has been assigned to someone.   So I think we can expect this to be 
resolved at some point.   

I think it would be helpful to add relevant info to this bug like the comments 
from Michael Meier and any others that are relevant to time keeping issues 
with glibc and the new linux nanokernels.  The more information the glibc devs 
have about this the more likely it is that they will actually fix things.

Prior to the nanokernel changes in 2.6.26 I was having very good results with 
the LinuxPPS patch set with offsets that seldom exceeded 5us and that were 
mostly <= 2us.  Since the nanokernel changes my offsets are about 10X higher 
with a nanosecond patched glibc and without those patches the offsets were an 
additional 10X worse.  It is fairly clear that there are problems with 
timekeeping with the new nanokernels.   At least some of this is because of 
issues with glibc not being in sync with the new nanokernels but there could 
also be issues that still need to be resolved in the kernel as well.

ntpd using a microsecond gettimeofday could account for some of this but I was 
unable to test this.  Since I don't know what is causing the issue that I am 
seeing when librt is linked into ntp it might be worth while for others to 
test this as well to see if it is an isolated problem.

Hal