LKM Timemark Driver

[Gary E. Miller]

Yo MLewis!

On Mon, 27 Aug 2018 22:07:55 -0400
MLewis via devel <devel at ntpsec.org> wrote:

> >> 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.  
> > Yes, thus the need for the PPS timestamp AND the TM2 timestamp.  
> "In timemark mode however, the timestamping for the PPS pulse and the 
> genera-tion of the
> echo pulse happen immediately after one another, both in the
> interrupt handler, with very little delay."

Yes.

> So his PPS Timestamp is the one made in the Kernel. As was his 'echo'
> timestamp, compared with the Timemark. The PPS Timestamp has
> interrupt lag. The Echo Timestamp doesn't. Echo Timestamp offset from
> Timemark time gave the best results, as no Pi kernel interrupt lag
> and the delay in taking the Echo Timestamp is in the same direction
> as the delay in propagation and ublox Timemark timestamp, so those
> errors are aligned, hence minimized. I don't know if I'm saying that
> correctly.

I think that is close.  The devil is in the details.  Thus I want to
see a working implmentation, and its stats.  If someone codes it
up I'll run tests against my Rb.


> "Strictly speaking, the PPS pulse isn�t even necessary for this
> process. One could simply generate a pulse on the external interrupt
> line once per second at a known time. "

Yeah, how do we get that once per second at a known time w/o PPS?

And why bother when PPS is right there.

> And my LKM timestamps to know that time. Like the Echo Timestamp,
> only initiated by a timer in the kernel. 

Except then the time is not known.  Any timer in the kernel is
not precise or stable.

> > The time from clock_gettime() is very coarse.  Not up to our needs.
> > On a Raspberry Pi 3B+ running 64 bit kernel the granularity is only
> > 52 ns.  
> I'm currently using REALTIME_CLOCK. There's also the thread clock and 
> the cpu clock.
> He was doing his timestamps in the kernal, so whatever precision was 
> available to his patch has to be available to a LKM.

Yup.  That will be the nexxt area to work on after this.

> >> If a PPS feature was added, the GPS PPS could trigger the next
> >> "timemark cycle", and the timemark trigger times could be aligned
> >> with GPS UTC. No real benefit.  
> > Yes, plus the interrupt latency that we are trying to determine.
> > Which is why the Timemark method subtracts the two.  
> Isn't that his MEASUREMENT mode.
> But his best results were with TIMEMARK mode?

hard to say.  His statistics were weak.  No standard deviation, not
comparison to a better standard, etc.  We'll try it all and compare.

> >> As I'm implemented it, as system time is disciplined, then the
> >> repeating pulse cycles will align with the disciplined system time,
> >> as the timing runs (msleep, usleep, udelay, spins) until the next
> >> target time (the time for the next pulse rise or fall) is
> >> recognized, comparing against timespec tv_current.  
> > I look forward to the results.  But your method is not what u-blox
> > described and Lukas implemented.  That is neither good, nor bad,
> > just different.  Many ways to skin this cat, let's get out the
> > sharp knives.  
> 
> I think it does match his Timemark Mode, just not initiating the
> trigger of the Timemark as an Echo of PPS, but as an intentional
> trigger from the kernel.

"Yes but", is not the same as "Yes".  Try a bunch of stuff and see what
sticks.


> But with Timemark 1 and 2 on the M8T, we can have four Timemark 
> timestamps and calculate four offsets, within each 1hz/PPS pass. More 
> offsets to filter for outliers and then smooth.

I doubt that more often helps.  For the same reason the best PPS
poll on a RasPi is 3, not 1.  But time is past to over0think it,
let's get to implementation, and tests.


> Personally I'm very 
> curious to see the jitter of each Timemark timestamp separately, to
> see if there's a difference in jitter depending on when in the second
> the kernel timestamp and ublox Timemark take place. As in, with the
> Pi CPU known for being "jittery", will one of the four offsets have
> less noise than the others. Does this change dynamically. etc.

Yes, mere replication is just the start.  This will be a new
tool to learn many new things.

> Worst case, I can add an input port and catch the PPS for people to
> play with calculating latency instead of Timemark Mode,

We need the PPS for traceability and camparability.  To prove this is
better or worse.  We'll need a lot of A/B.

> Or, as it's a LKM, anyone can add what they want.

Oh, yeah, everyone can recompile kernel modules.  :-)

> But the Timemark mode gives the best results... Implementing that
> first.

Looking forward to it!

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20180827/a47bb6b8/attachment.bin>