LKM Timemark Driver

[Gary E. Miller]

Yo MLewis!

On Mon, 27 Aug 2018 19:07:52 -0400
MLewis via devel <devel at 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 at 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
	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/4cd01ef4/attachment-0001.bin>