LKM Timemark Driver

[Achim Gratz]

MLewis via devel writes:
> The PPS becomes irrelevant.
> The PPS has all of the interrupt lag. Why introduce all that variable error.

Yes.  It is still there however to be used independently if one wishes
to do that, but ntpd currently lacks the facilities to process multiple
sources into a single view of time.  But even with the current
implementation it should be useful for monitoring.

> The thesis confirmed what I suspected, that the best results are from
> a kernel timestamp of the outgoing trigger that has the ublox generate
> its Timemark timestamp. Their difference is your offset.

That's the result of there being no interrupt involved on either side of
the measurement.  This part is uBlox specific, some other modules can
timestamp external signals, but use an interrupt to do so.  It is
probably still a net win to reverse the measurement as I expect the
interrupt latency and/or jitter to be smaller in that direction in most
cases.

> The critical part is in the kernel, in order, GPIO high, then timestamp.
> That's easy. It's all of the overhead for safe multi-port LKM.
> Then hitting the target times reliably and with what precision is
> available.
> And a stream of timestamps back to user space.

If you want to be really precise about it, timestamp before and after
setting the GPIO.  For the rasPi there shouldn't be a difference since
the only thing you're doing is writing a register, but other ways of
controlling a GPIO might take some longer time.

[…]

Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada