Yo MLewis! On Mon, 27 Aug 2018 22:07:55 -0400 MLewis via devel <devel@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
g...@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
pgpT0KbRczs3m.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
