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

[Michael Meier]

>> 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

I'm impressed. Would be interesting to know when they put that in - 
because it should have been rather useless and a waste of cpu before 
kernel 2.6.26...

>> Dec 26 11:02:31 epia ntpd[13820]: precision = 1.000 usec
>> Dec 26 11:29:41 epia ntpd[13969]: precision = 1.541 usec

The second one does look good, was the first one with a non-nano kernel?

> 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:04:53 office ntpd[11573]: proto: precision = 0.177 usec
>       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.

well naturally power saving is going to interfere with any timing loop.

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

The absolute value is pretty useless, I agree. But it does tell you if 
ntpd gets time from the kernel with ns or us resolution, by checking if 
the numbers after the period are always 000.
The absolute value basically only tells you how long your system takes 
for executing a system call. Doing a system call is a very expensive 
operation, so it will take A LOT more than 0.001 us on ANY system 
available today. It should be a bit faster with 64 bit kernel and 
userland, but still expensive. 1.5 us on an EPIA is actually better than 
I expected, I'm getting 0.7 us on a Pentium 3 and 1.3 us on a Pentium 4 
(yes, they were actually a lot slower than the pentium 3 in that, and 
that is not the only thing they sucked at - luckily intel fixed it with 
the core2).
This should however not have a bad effect on timekeeping, as that 
overhead is pretty constant, so it will give you an constant offset.
-- 
Michael Meier, HPC Services
Friedrich-Alexander-Universitaet Erlangen-Nuernberg
Regionales Rechenzentrum Erlangen
Martensstrasse 1, 91058 Erlangen, Germany
Tel.: +49 9131 85-28973, Fax: +49 9131 302941
michael.meier at rrze.uni-erlangen.de
www.rrze.uni-erlangen.de/hpc/