[Bug libc/9690] glibc time functionality broken with kernel 2.6.26 and later

["hvengel at astound dot net" <sourceware-bugzilla@sourceware.org>]

------- Additional Comments From hvengel at astound dot net  2009-05-07 23:10 -------
(In reply to comment #5)
> (In reply to comment #4)
> > Please do not mix two things:
> > 
> > - the kernel now exposes nanoseconds instead of microseconds.  That's a
> > kernel ABI break.  It is announced via a STA_NANO flag in timex.status,
> > but still, old applications are broken when started under kernels >=
> > 2.6.26.  That's really a concern as it's not even easy to notice while
> > it can irritate users (unstable ntp time).
> 
> I'm not sure this is true. The kernel internally multiplies microseconds up to
> nanoseconds if the STA_NANO bit is not set. So old applications should behave
> properly.

The issue is that when ntp builds it looks in sys/timex.h (IE. the glibc
timex.h) and if it does not see STA_NANO and friends it builds as a microsecond
only app with the assumption that it is going to be running against a
microkernel.  When this happens it never asks the kernel if it is a nanokernel
and this results in things not working correctly.  

What LinuxPPS users noticed was that using the combination of a non-nano aware
ntp with the newer nanokernels resulted in time keeping that was, by our
standards and expectations, unstable and we would see the offsets slewing
through a +-500 microsecond range.  Tis was almost two orders of magnitude more
than we were seeing before the switch to the nanokernel.  There was a long
string of emails on the linuxpps email list about this and it almost goes
without saying that we were not happy campers.  We were clueless about what the
cause was and it took a while for us to figure out that the missing STA_NANO &
friends stuff in sys/timex.h was a big part of what we were seeing.  We
discovered this because we have some users who also use FreeBSD and they were
able to point out that for some reason ntp was not detecting the nanokernel like
it should. 

As soon as we added the STA_NANO & friends declarations to sys/timex.h and
rebuilt ntp these issues were greatly improved and offsets were reduced by an
order of magnitude.  The offsets were still higher than before the nanokernel so
there were other issues as well but this was a very big one.  I think John's new
convergence kernel patch may be the other piece of this puzzle.   So I don't
think it is that the kernel is giving out the time in a different format (in
fact it is not) but rather it has something to do with how ntp interacts with
the kernel to make frequency adjustments to the clock (that my guess anyway). 
It clearly does something different if it is in microseond mode than it does in
nanosecond mode. 


I should add that this appears to be a Linux only problem and ntp is not having
these issues on any other OS with a nanokernel.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=9690

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.