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

[Udo van den Heuvel]

Hal V. Engel wrote:
>>>> 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

A faster machine than my VIA Epia EK8000? (800 Mhz VIA Nehemiah CPU).
(I have a 1 GHz C7 board (VIA Epia LT 100000) lying around to install later)


> But I also see lot of variability in this like:

I see:

Dec 26 11:02:31 epia ntpd[13820]: precision = 1.000 usec
Dec 26 11:29:41 epia ntpd[13969]: precision = 1.541 usec
Dec 26 11:30:55 epia ntpd[14123]: precision = 1.551 usec
Dec 26 11:32:07 epia ntpd[14211]: precision = 1.542 usec
Dec 26 14:18:52 epia ntpd[7614]: precision = 1.542 usec
Dec 27 08:15:25 epia ntpd[9994]: precision = 1.552 usec
Dec 27 08:17:47 epia ntpd[10089]: precision = 1.541 usec

(after Dec 25 I installed the NO_HZ kernel and built a new ntpd?)

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

Hmmm. HPET clock here but slowish CPU? 1 GHz C7 *could* help a bit I guess.

> My hpet clock runs at 25MHz which means that it should be able to resolve 

Slower here I guess.

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

Indeed, but it is perhaps worthwhile to tune the software so that the 
maximum performance can be reached.
If I understand things correctly it is that the ntpd I build on the 
Fedora 10 system with LinuxPPS *can* do the stuff needed for sub-1-us 
steps but the hardware is a limiting factor (timing, cpu, etc).


Udo


PS: my Motorola UT Plus Oncore are in the mail.
Need a GPS antenna, possibly low-power outdoor model as well as cabling 
to mount he GPS module in the Epia and connect the antenna to the 
outside with > 5m cable...
Any tips? (thicker coax?)