LKM Timemark Driver

[MLewis]

Gary,

On 27/08/2018 8:56 PM, Gary E. Miller via devel wrote:
> 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.
"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 correctly.

"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. "

And my LKM timestamps to know that time. Like the Echo Timestamp, only initiated by a timer in the kernel.
  

> 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.

>> 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?

>> 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.

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. 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.

Worst case, I can add an input port and catch the PPS for people to play 
with calculating latency instead of Timemark Mode, optionally:
* timestamp it, count it and provide it as another message, or
* catch & timestamp, echo & timestamp, count PPS and Trigger and provide 
them as messages.

Or, as it's a LKM, anyone can add what they want.

But the Timemark mode gives the best results... Implementing that first.

Michael