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@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
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
