On 2010-04-15, Miroslav Lichvar <[email protected]> wrote: > On Wed, Apr 14, 2010 at 11:55:54PM +0000, unruh wrote: >> On 2010-04-14, lhommedumatch <[email protected]> wrote: >> > The ntpgmtaceb (this clock loses 1.10e-11second every second => ie 8.6 >> > 10e-7s each days) is providing zda+pps, I have worked on using PPS >> > with LinuxPPS. >> > But I need to patch the kernel. I'm using CentOS 5.4 => linux2.6.18. >> >> Why do you need to patch the kernel? Just use shmpps or gpsd to deliver >> the PPS time to ntpd to discipline the clock. Now, that may only give >> you 1usec accuracy, instead of 1/2usec, but since discussion was about >> ms, that should not be the problem > > Userspace timestamps may decrease the accuracy by more than just 0.5 > us. When I compare kernel timestamps and timestamps from gpsd, there > is a 20-40us difference, even when the gpsd process has real time > priority and the machine is otherwise idle.
OK, I have wondered about this. Have you tried to control the interrupts? Ie, run a program which times and puts out data on say one of the parallel port lines and run that into the serial port interrupt line so you can actually see the difference in time between the assertion of the signal and the receipt of the signal by gpsd/serial port? I know I did this for the parallel port where I used my own ( well, a kludged version of the parallel interrupt service module from "Linux Device Drivers" by Alessandro Rubini and Jonathan Corbet, published by O'Reilly & Associates.) I found roughly a 1usec difference between the time the line was asserted and the timestamp from the interrupt service routine. Ie, it took somewhere around 1usec for the routine to actually assert the parallel port line, and then for the kernel to launch the interrupt response and for the interrupt service routine to receive the signal and timestamp that receipt. If the serial port interrupt service really adds 20us to the service time, I feel justified in my unsubstantiated worries about the serial port route. Ie, I am not advocating userland timestamping, but using a module to do the timestamping. A module does NOT require kernel recompilation. The only problem I have with my module is that I must erase the kernel parallel port module, because if it runs, it destroys the parallel port, even if it is subsequently removed (ie makes it unuseable by anything else.) Ie, instead of leaving the parallel port in the state it would have had, had that module never been loaded, it leaves it in a state where the interrupt can never again be used without reboot (well, at least by me, which is not saying much). > > Of course, for 1ms requirement this doesn't matter. > _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
