[LinuxPPS] Recommendation / Re: Stats & architectures

[James Boddington]

Bernhard Schiffner wrote:
> Am Montag, 17. März 2008 08:03 schrieb James Boddington:
> ...> clemens at dwf.com wrote:
> 
>> 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.
> Nice summary.
> To be honest: I read the ntp.c -code, found the important part with 
> freq_adj = ... and was not able to deduct, what was going on there in 
> detail.
> Some variables are set by NTPD, others relate to the clocksource, some are 
> read, others written and never used anywhere.
> To ask only a simple question: The behavior seems to be dramaticaly 
> dependend form the NTPD-maxpoll parameter. How does it come into the 
> calculation there?

At the moment do_adjtimex() is being called every 16 seconds. That corresponds 
with PPS(1) having minpoll 4.

> But if you are common with the details there, can you ask Roman Zippel or 
> some of the other gurus about the reason for this loss in numeric 
> resolution, please?

I am making this up as I go. As for the loss of numeric resolution that could 
be because of the microsecond clock and ntp being compiled for a microsecond 
clock. As everything is microsecond it makes sense to pass a microsecond offset 
to adjtime.

Found http://lkml.org/lkml/2008/3/14/267 while looking for information about 
STA_NANO. Reading that thread it looks like what I said about the offset is 
changing. http://lkml.org/lkml/2008/3/14/273 is the post that caught my 
attention, do_adjtimex() will accept nano or micro depending whether STA_NANO 
is defined. STA_NANO also has a bit to do with how ntp is built.
> ...
>> 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.
> Mean "close" to 30.000 instructions to be processed until the readout is 
> available.
> 
> As I mentioned earlier: I belive in an (about) 50 µs "blackout" an 
> interrupt causes, until it can happen again. Do you see a chance to prove 
> this with your  environment?

The easiest way I can think of would be to try in quick succession what I tried 
below.

> Interesting would be to see the differences in hardware (scope), 
> irq/handle.c-time and pps_event().

I don't have a scope. All I have done with the serial port is connect a data 
pin on the parallel port to dcd on the serial port.

get time stamp
outb(255,0x378) // trigger dcd via parallel port data line
read pps time stamp

I got an average of 9.1us from triggering the parallel port to getting the time 
stamp in irq/handle.c for irq 4.

-- 
    James