[ntp:questions] How do I validate my PPS clocks?

unruh unruh at invalid.ca
Thu Feb 28 17:44:25 UTC 2013


On 2013-02-28, ramadog at gmail.com <ramadog at gmail.com> wrote:
> On Thursday, February 28, 2013 3:53:22 PM UTC+10, unruh wrote:
>> On 2013-02-28, ramadog wrote:
>> > Up to that 8us point it is the same behaviour I have been seeing since 2008.
>> > I did this graph April 11 2008 http://users.on.net/~boddingt/irq-pps.png
>> > Blue line is a time stamp taken at the beginning of the irq code and the red
>> > line taken in the serial code.
>> 
>> You have an offset from 0 for the irq.c timestamp. How do you know that
>> it took 1/2 a us or so Until that point?
>
> The graph represents the actual time stamps for the pps using getnstimeofday()

Ah. OK. So the time difference between the irq.c timestamp and 0 is
irrelevant (or perhaps is a measure of the time to get the timestamp
from the kernel.)


> I was getting at the time. It is possible I had stopped ntp so the system was
> free running while I collected that data. I look at it as the difference
> between grab the event time as soon as possible and decide later if it can
> be used vs wait until we are sure then grab the time. It was a 2.6.something
> kernel and I still see similar with the 3.5.7 kernel I am currently using.
>
> What got my interest was the code posted earlier in this thread to estimate the 
> delay. 1 person had a delay similar to what I get and that code was close for
> me and my p3-600 which is a little faster than a 8088.

I was not accusing you of anything. I am simply astonished at the serial
driver code, and its interminable delays in getting a timestamp. That
timestamping should be the first thing it does, and it should be
figuring out whether it needs it afterwards. The 2us to get from the irq
to the serial driver also seems a long time. I would have expected much
faster on a 600MHz system.



More information about the questions mailing list