On Fri, Dec 23, 2011 at 10:06 PM, unruh <[email protected]> wrote: > If you really go to stamping the interrupt directly as it comes in on > the kernel level, rather > than waiting for a driver (eg the serial driver) to report that the > itnerrupt has occured to userland, you can get it down to 1-2us.
That is exactly how the Linux PPS system works. The kernel level driver is all of about a dozen lines of code. It is very simple. When the interrupt happens the driver copies the hardware nanosecond clock to some location in RAM and sets a flag that says "data available" A user land program waits for the flag. When it sees the flag set it can read the counter value that was saved by the driver and then the flag is re-set. It is unimportance how long it take the program to notice there is data and read it, so long as it does so before the next pulse. Linux does not queue the data. The next pulse over writes the time stamp. As you say 1 or 2 uS is about what it gets. On my system the nanosecond clock jumps in 1000 nS steps But notice this is not just a pulse per second interface. It is a pulse interface and can time stamp random pulses too. I know it works for 60Hz pulses. The interpretation of what to do with the data is a user land thing. NTP uses it to sync the clock. Other people use it for general-purpose pulse timing. Chris Albertson Redondo Beach, California _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
