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