Achim,
On 20/08/2018 1:35 PM, Achim Gratz via devel wrote:
.. 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.
Exactly! It's been on my todo list for a couple of years, but I wasn't
motivated to get into a LKM to get to kernel space to make it
worthwhile. Although I suspected that even from user space, the result
would be better than some PPS.
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.
Which is why I'm ignoring the PPS driver.
Trivial to include PPS in this LKM.
This allows the timemark triggering to be aligned to GPS TOS.
The benefit of being able to align the timemark triggering to PPS, hence
TOS in the GPS module, is that we may find different jitter depending on
when within a second the timemark is performed. Until we have data, we
won't know.
You can actually drop the PPS in this case, as it will provide no benefit.
Agreed. Except possible benefit with alignment, as described above.
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.
I've already got single or dual timemarks rise & fall coded, along with
PPS or system time TOS alignment.
I see it as a stream of timestamp messages returning to user space.
Multiple LKMs is worth considering. I'll have to work through the
implications.
It should be simple enough to take mine and split it up.
Michael
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
