LKM Timemark Driver
Gary E. Miller
gem at rellim.com
Tue Aug 28 02:58:14 UTC 2018
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."
> 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
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
> 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
Looking forward to it!
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
Size: 851 bytes
Desc: OpenPGP digital signature
More information about the devel