LKM Timemark Driver

Gary E. Miller gem at
Tue Aug 28 00:56:04 UTC 2018

Yo MLewis!

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

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at  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: <>

More information about the devel mailing list