Repeat. Didn't go out in text format.
On 20/08/2018 10:22 AM, MLewis via devel wrote:
Udo,
On 20/08/2018 9:43 AM, Udo van den Heuvel wrote:
Michael,
What else could we do with the timemark functionality?
See what is suggested at
https://lists.ntpsec.org/pipermail/devel/2018-August/006447.html ?
With kernel level timestamps back in user space, paired with the GPS
Timemark message, you can do whatever you want with them.
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.
This is because the ublox doesn't know the time of origin I guess?
Correct. You need both sides.
With PPS, you get one offset from system time, but with incoming
latency including interrupt lag.
Using Timemarks give you FOUR kernal level latency ports going
high/low with kernel timestamps.
You don't need the higher latency PPS for calculating offsets and
disciplining. See the thesis results.
Maybe make it an elaborate PPS device that can also be read?
Udo
Define "elaborate PPS device".
Once this LKM is working, you can make a copy and play with it.
Perhaps with using the greater precision of CPU Time - if you can find
a way that will keep the LKM in the same core for the duration of your
measurements.
Michael
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel