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

[Hal V. Engel]

On Saturday 10 January 2009 23:35:18 Udo van den Heuvel wrote:
> Udo van den Heuvel wrote:
> > Hal V. Engel wrote:
> >> I was using ntp-4.2.5p135 when I was having this problem.  I moved back
> >> to 4.2.4p6 (latest stable version) and tested again.  This appears to be
> >> working OK with LIBS="-lrt".  So it appears that there were issues with
> >> the version of ntp I was using.
> >
> > So I just patch the Makefile?
> > Or is there a ./configure trick to use librt?
>
> In the redhat rpm for ntp I find:
>
> # clock_gettime needs -lrt
> sed -i.gettime 's|^LIBS = @LIBS@|& -lrt|' ntp{d,q,dc,date}/Makefile.in
>
> But my precision looks like:
>
> Dec 26 11:02:31 epia ntpd[13820]: precision = 1.000 usec
> Dec 26 11:29:41 epia ntpd[13969]: precision = 1.541 usec
>
> So?

I see this:

Jan 10 18:12:11 office ntpd[26249]: precision = 0.720 usec
Jan 10 18:13:16 office ntpd[26339]: precision = 0.720 usec

But I also see lot of variability in this like:

Jan  9 10:00:06 office ntpd[11058]: proto: precision = 0.790 usec
Jan  9 10:01:50 office ntpd[11294]: proto: precision = 0.212 usec
Jan  9 10:03:46 office ntpd[11494]: proto: precision = 0.599 usec
Jan  9 10:04:53 office ntpd[11573]: proto: precision = 0.177 usec
Jan 10 10:04:06 office ntpd[11024]: proto: precision = 0.393 usec

Looking back over my logs I see this having values between 0.107usec and 
1.367usec.  This machine gets restarted on an almost daily basis and the 
system log goes back to mid Nov.  I should add most of the precision data from 
my log is before I built ntp with LIBS="-lrt".  

Looking at the NTP code the precision number is arrived at by getting the 
system time in a tight loop and comparing the times in each iteration of the 
loop.    If the time produced by the system clock is fine grained enough this 
is more a measure of how fast that loop runs rather than an indication of the 
actual resolution of the clock.   In fact the comments in the code make it 
clear that the loop iteration speed is the limiting factor if the clock is 
very fine grained.  

One other interesting thing in the code is a comment about the OS using the 
low order bits of the fractional seconds part of the time to hold non-time 
data.  In other words on systems with low resolution timers the low order bits 
of the fractional seconds part of the time could have counter data and the 
code says that in some cases the OS will use these low order bits as a counter 
that is incremented each time the get time function is called in order to make 
sure that the time is monotonic (IE does not appear to stand still).

My hpet clock runs at 25MHz which means that it should be able to resolve 
times as small as 40 nanoseconds.  But it appears that the loop used to 
measure the precision needs significantly more than 40 nanoseconds for each 
iteration.  This is on an AMD 64 4800+ machine but I suspect that much of the 
time when ntp is doing the precision test that the CPU is running at 1 GHz 
rather than it's full speed of 2.4GHz.  This would make the loop much slower 
and it would also in part account for the wide range of values I am seeing.

After seeing this in the code I concluded the the precision number is not very 
meaningful.

Hal