MLewis via devel writes: > I believe it should be a driver as a Loadable Kernel Module.
Yup. > I'm working on one now. Selectable triggers of Timemark 1, rising and > falling, and Timemark 2, rising and falling, providing up to four > timestamps for calculating four offsets, observing noise, etc., once > the timestamps are back in user space. If you want to measure the interrupt delay + jitter, you really need to do this in the PPS driver. Unless I'm missing something, your implementation would do something I proposed a few weeks ago, namely skip dealing with PPS in altogether and correlate kernel and GPS time via timestamping on the GPS. Just to mention it again, the other way to get rid of the interrupt jitter is to poll the GPIO. You know precisely when the next PPS should come, so hires delay timers will allow you to box the transition in. > A cycle of triggering timemarks (one cycle per second) can be initiated: > - by the PPS so it's aligned with GPS UTC, or Traveling through two device drivers to get the PPS echo out doesn't seem appealing to me. > - it can run without PPS, aligned with system time TOS. See above. > Best guess, I've coded it to trigger timemarks at 250 ms, 415 ms, 580 > ms and 745 ms, to keep those tasks spaced apart, yet away from the > module producing PPS at TOS and its epoch message delivery. We can see > results and modify when we'd like those to occur. You can actually drop the PPS in this case, as it will provide no benefit. > I'm held up deciding on the method of sending messages for each > Trigger Timestamp from the kernel module back to user space. Looks > like it should be a socket. I'd model it after the PPS API, just create two devices for each timemark generator that provides the sequence number and kernel times for assert and clear edges. There might be another pair of devices that provides the measurement results in the same form, but I'd start out doing that in userspace as each device will format these differently. This task sounds like a good excuse to use the BPF in-kernel VM. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel