[LinuxPPS] Recommendation / Re: Stats & architectures

[James Boddington]

clemens at dwf.com wrote:
>> Rodolfo Giometti wrote:
>>> I suppose you shouldn't need to much efforts in getting the HARDPPS
>>> support from Ulrich Windl's code and move it into LinuxPPS.
>> What benefit(s) does HARDPPS support bring?
>>
> Well, you would expect that having the kernel itself detect the time 
> differences
> from its clock to the pps signal would result in a 'tighter' control of the 
> clock
> than the ntpd (userspace) code doing this and then passing this information to
> the kernel using the adjtime system call.  
> 
> With a clock with (only) microsecond resolution, and an adjtime system call 
> with only microsecond resolution one has to expect that the clock frequency/
> phase is zig-zagging around the 'correct' value a lot more than if these were
> both configured in nanoseconds.  The HARDPPS support would put the entire
> ntp calculation in the kernel, thus at least the adjtime system call is no 
> longer
> relevant.


I modified kernel/time/ntp.c to use a smaller time constant and to use the pps 
time stamp directly instead of the offset fed to it by ntp when the offset goes 
below 50 milliseconds. The kernel time constant modification because I don't 
like how badly modern linux kernels follow the pps for me and using the pps 
directly was me wanting to see how hard it was to get something basic working 
after staying up late Friday night catching up with this list and reading this 
thread.

Linuxpps uses getnstimeofday() so a nanosecond time stamp is available. I found 
do_adjtimex() in kernel/time/ntp.c is given a microsecond offset. Internally 
do_adjtimex() multiplies the offset by 1000 giving a nanosecond offset with the 
last 3 digits 000. My approach was simple, use the pps time stamp directly to 
get an offset. I now have a nanosecond offset instead of a microsecond * 1000 
offset. One side effect of this is plotting the frequency vs time the graph 
looks a lot smoother than what I had previously. I seem to get more smaller 
changes and fewer larger changes to the frequency.

What I did was rather simple and there is no filtering. At the moment only the 
raw pps time stamp is used. I have the time stamp the kernel uses being 
exported via /proc. I have a script logging those time stamps. A plot of the 
last 19 hours is at http://aiken.dnsalias.org/offset.png

The kernel is staying within 1us of when it sees the pps. The world from ntp's 
perspective can be seen at http://aiken.dnsalias.org/cgi-bin/linuxpps

A bit off topic to this thread. Any one looking the my linuxpps page will see a 
5us difference between GPS_NMEA(0) and PPS(1). I wanted to know how much delay 
there was from when the kernel learns of the interrupt to when the linuxpps 
time stamp was taken. GPS_NMEA(0) is the linuxpps time stamp. PPS(1) is my own 
time stamp taken at the start of handle_IRQ_event() in kernel/irq/handle.c. 
There is a mean delay of 4.8us from when the kernel decides there is an 
interrupt and does something about it to when pps_event() gets a time stamp. 
This is with a p3-600.

-- 
    James