LKM Timemark Driver

[MLewis]

Gary,

On 27/08/2018 10:58 PM, Gary E. Miller via devel wrote:
> Yo MLewis!
>
> On Mon, 27 Aug 2018 22:07:55 -0400
> MLewis via devel <devel at ntpsec.org> wrote:
>

>> "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?
The Timemark Mode wasn't even using PPS times, but the Echo Timestamp 
and the Timemark timestamp. What the time is doesn't matter. What 
matters is that you know what time that is, as in, to system time, so 
you have an offset to from system time to the GPS UTC timemark/timestamp.
That's the beauty of it. You don't need a precise Pi interrupt, you 
don't even need any Pi interrupt. The precision is in obtaining the 
kernel timestamp and the timemark.

> And why bother when PPS is right there.
Because running interrupts is said to cause CPU jitter. And PPS isn't 
right there, you have to code it. Versus something as simple as msleep, 
and a timestamp of the trigger time.

>
>> 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.
Yet, it's the kernel within kernel space that is exactly where he gets 
the Echo Timestamp from that gives the great Timemark Mode results...
>>> 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.
> hard to say.  His statistics were weak.  No standard deviation, not
> comparison to a better standard, etc.  We'll try it all and compare.
>
>> 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.

yup

I'm wanting numbers.

Michael