<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#fffffe" text="#000000">
Udo,<br>
<br>
<div class="moz-cite-prefix">On 20/08/2018 9:43 AM, Udo van den
Heuvel wrote:<br>
</div>
<blockquote
cite="mid:a5b7ceca-a2c4-56e0-4674-b8116c44629a@xs4all.nl"
type="cite">Michael,
<br>
What else could we do with the timemark functionality?
<br>
See what is suggested at
<a class="moz-txt-link-freetext" href="https://lists.ntpsec.org/pipermail/devel/2018-August/006447.html">https://lists.ntpsec.org/pipermail/devel/2018-August/006447.html</a> ?
<br>
</blockquote>
With kernel level timestamps back in user space, paired with the GPS
Timemark message, you can do whatever you want with them. <br>
<br>
<blockquote
cite="mid:a5b7ceca-a2c4-56e0-4674-b8116c44629a@xs4all.nl"
type="cite">
<blockquote type="cite">I'm held up deciding on the method of
sending messages for each Trigger Timestamp from the kernel
module back to user space.
<br>
Looks like it should be a socket.
<br>
</blockquote>
<br>
This is because the ublox doesn't know the time of origin I guess?
<br>
</blockquote>
Correct. You need both sides. <br>
With PPS, you get one offset from system time, but with incoming
latency including interrupt lag. <br>
Using Timemarks give you FOUR kernal level latency ports going
high/low with kernel timestamps. <br>
You don't need the higher latency PPS for calculating offsets and
disciplining. See the thesis results.<br>
<br>
<blockquote
cite="mid:a5b7ceca-a2c4-56e0-4674-b8116c44629a@xs4all.nl"
type="cite">Maybe make it an elaborate PPS device that can also be
read?
<br>
Udo
<br>
<br>
</blockquote>
Define "elaborate PPS device". <br>
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. <br>
<br>
<br>
Michael<br>
<br>
<br>
</body>
</html>