LKM Timemark Driver

[MLewis]

Hal,

I know some of that.
And I think I understand some more.

On 28/08/2018 4:06 AM, Hal Murray via devel wrote:
> Could somebody please review this discussion.  I'm trying to catch up.  I can
> follow most of the details, but I'm missing the big picture.
>
> What GPS device is involved?  Is there a handy board?  What does it actually
> do?  I'm guessing it time stamps an input pin.  (Some other GPS unit does
> that.  I forget which one.)
A number of the ublox M8 series have a Timemark feature.
On a pin going high or low, the GPS module takes a snapshot. It 
maintains a count of how many times that pin goes high or low.
At the next epoch (1hz/PPS, GPS UTC recommended), if there were 
Timemarks, a ublox TIM-TM2 messages goes out with those counts and a 
Timemark (timestamp) of the last high and last low of that pin. Then the 
values are reset.
Other ublox may have that feature.
The M8T has two pins, EXTINT0 and EXTINT1, for Timemark 1 and Timemark 2.
Some boards populated with an NEO-M8T are available in the $95 USD 
range, but only some have access to the EXTINT pins.

> Does the PPS logic on the Raspberry Pi use a counter to avoid interrupt
> latency?
I don't know.
> What does the proposed kernel mod do?  I'd guess grab a time stamp
> before/after flapping an output pin.
According to a thesis with a published patch, the proposed kernel mod:
- takes the GPS PPS in on interrupt, with a kernel timestamp of that 
event (PPS timestamp)
- Echos the PPS out on another GPIO port, takes a kernel timestamp of 
that event (Echo timestamp)

The thesis said in Measurement Mode it uses the PPS timestamp, Echo 
timestamp and the resulting TM2 timemark of the rising pin to calculate 
the latency of the PPS interupt and an offset of the timestamp to GPS UTC.

In Timemark Mode, it used the Echo timestamp and the TM2 Timemark for an 
offset and got even lower jitter than PPS mode.
The thesis states that for Timemark Mode, the PPS isn't even needed, 
just a port signal timestamp.

The Timemark Mode has particularly good results as it avoids involving 
the variable latency of PPS interrupt, and the delay in propagation of 
the Echo signal and the Timemark function happens more or less in 
parallel to the kernel making the timestamp of the Echo event, so 
they're in the same direction thereby minimizing the difference of the 
two events trying to happen at the same exact instant.

 From the thesis:

" The kernel reported the PPS echo feature as
being implemented for the Raspberry Pi�s GPIO pins. This was not 
actually the case,
it only wrote a line to the system log instead of actually generating a 
signal. We
implemented this by changing the interrupt handler to a threaded 
interrupt handler.
After raising a GPIO pin in the interrupt handler, the subsequent thread 
sleeps for
100ms and lowers the pin again.  This results in an echo pulse of 
roughly 100ms
length."

" 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. However having the echo signal triggered by a PPS pulse instead of 
a timer
function or something similar, has several advantages. Having a common 
API makes
the implementation much more portable, without it, we would have to 
write code
for every different piece of hardware which can be used to send the echo 
signal
(GPIO, parallel port,...). Another advantage of this method is that the 
timestamping
and the signal generation happen inside the kernel, in an interrupt 
context. This
means that the time between those two events is not increased by context 
switches
and has a very low chance of being preempted by other interrupts. "


" Additionally we introduce timemark mode, which uses the
PPSAPI echo feature and the u-blox timemark feature to generate offsets 
which don�t
include local interrupt latency. On top of this, measurement mode can be 
used to
record PPS latency for individual PPS pulses. "

The thesis reports jitter:
Oncore PPS 1141 ns,
M8T in PPS mode, 804 ns
M8T in Timemark mode, 222 ns

Additional experiments regarding CPU load gave results more or less in 
the same range.

I don't believe anyone has replicated this results yet.


Patches, LKM

To get the Timemark Mode capability, we need a kernel level timestamp of 
the output port that triggers the M8 Timemark.
We also need that outgoing signal generated.

I'm writing a LKM Timemark driver that will drive an output port and 
timestamp it going high or low, repeating at a specified time and pulse 
width. Multiple ports can be independently driven. I'm thinking of the 
Timemark 1 and Timemark 2. Anyone will be able to modify it to meet 
their needs.

If a patch or patches gives the PPS interrupt a functioning Echo, then 
the GPS PPS can trigger an Echo to drive the GPS's Timemark pin, 
avoiding needing something to time and trigger an output signal to drive 
the Timemark.
The low jitter Timemark Mode needs that Echo to have a kernel level 
timestamp.
If the PPS interrupt also has a kernel level timestamp, although the 
thesis shows much worse jitter than Timemark mode, people can experiment 
with calculating PPS latency.

I hope I got that right.

Michael