[ntp:hackers] u-blox reference clock driver

[Achim Gratz]

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