Yo MLewis! On Mon, 27 Aug 2018 19:07:52 -0400 MLewis via devel <devel@ntpsec.org> wrote:
> Gary,
>
> On 27/08/2018 6:38 PM, Gary E. Miller via devel wrote:
> > Yo MLewis!
> >
> > On Mon, 27 Aug 2018 18:24:01 -0400
> > MLewis via devel <devel@ntpsec.org> wrote:
> >
> > The key thing I, and others, want from the Lukas patch is the
> > PPS out when the kernel detects the PPS. Without out, nothing much
> > else matters.
>
> The PPS becomes irrelevant.
> The PPS has all of the interrupt lag. Why introduce all that variable
> error.
Because that is how U-blox tells us to use Timemark? The point of Timemark
is to remove the interrupt lag/jitter.
> 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.
> Their difference is your offset.
> The critical part is in the kernel, in order, GPIO high, then
> timestamp. That's easy. It's all of the overhead for safe multi-port
> LKM. Then hitting the target times reliably and with what precision
> is available.
> And a stream of timestamps back to user space.
Easy? I look forward to many pretty graphs and a howto.
> > What is your definition of "Timemark"? I thought that was the
> > time stamp from the u-blox on receipt of the PPS out from linux?
> The Timemark timestamp returned in the next TM2 if triggered in an
> M8, specifically M8T's EXTINT0 or EXTINT1.
OK, we agree. You were using it inconsistently in your email.
> > From user space, various commands, including: open port, High,
> > Low, Toggle, Pulse is Positive, Pulse is Negative, Pulse, Pulse at
> > ms past TOS, Pulse every ms, and pulsing available specifying
> > nanoseconds. Interesting.
> From user space people can send commands to the LKM and thereby grow
> their own trigger/pulse actions in user space by sending high, low,
> toggle, etc.. Or use the predefined Pulse At or Pulse Every.
Yes, interesting. I'll focus on Timemark for now.
> >> PAT017.165.250 will pulse GPIO 17 at 250 ms from tos, width 165 ms
> >> PAT018.165.580 will pulse GPIO 18 at 580 ms from tos, width 165
> >> ms
> > Which 'tos'?
> System time, specifically clock_gettime(CLOCK_REALTIME, &tv_current);
> This aligns the times timemarks are triggered with system time.
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.
> 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.
> 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.
> >> Then something in user space to receive the TM2 messages and the
> >> LKM's timestamps and match up the Timemarks with the triggering
> >> timestamps.
> > How does a daemon get the LKM timestamp? In the base case, as
> > Lukas had it setup, no need for such a thing.
> But that gave not so good results.
Better than I have ever gotten by a factor of 2. I would take that.
Plus it opened the door to further optimization.
When you have good results, send us the ntpviz link.
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
pgpnLnK0n61gG.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
