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 _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
