On 2013-02-28, rama...@gmail.com <rama...@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. _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
