[time-nuts] Raspberry Pi NTP server

[Trent Piepho]

On Sun, Jul 12, 2020 at 5:08 AM Matthias Welwarsky
<time-nuts at welwarsky.de> wrote:

>
> If you think about using an AM3358, there's zero reason to use a GPIO for PPS
> input. There are much better options, like the gptimer inputs or the eCAP
> engine, which runs on a 200MHz clock and is therefore able to create much more
> accurate timestamps.

A much better way to go for sure. There would be just the latency of
the PPS vs the capture block's clock, plus anything in the logic of
that block.  All the delays that happen afterward, both just in
getting the interrupt to the CPU and also in handling the interrupt in
software before a PPS timestamp can be generated, can be subtracted
out by using the timer.

How much difference does it make?  I've actually got data on that, see
attached graph.  This is for a Cyclone V, but it's very comparable to
an AM3358, other than being dual core.  The uncorrected jitter
histogram is similar to what using a GPIO would give.  Though it uses
a custom PPS driver, which I wrote to try to do a good job at
timestamping the interrupt consistently.  The time measured here is
the difference of the PPS timestamp vs 1 second on the system clock.
This means we have:

Jitter in the Telit JN3 GPS PPS signal
Delay for PPS hardware in CycloneV to detect an edge.  I think it had
about a 200 MHz clock.
Jitter in the system clock for τ=1 sec
All the delays getting that interrupt to the CPU over AXI,
interrupting the ARM, querying the INTC, etc. that I've already gone
on about for some length.
Software time spent in kernel code (Interrupt handler, GIC driver, PPS
driver), before we get to create a timestamp.

Of course this is just the jitter in this latency.  The constant part
we don't actually know.  And this is usually about 1.5 µs, but can be
up to 100 μs.

The Corrected part of the histogram is what you'd get with a capture
mode timer.  In this case the clock was 50 MHz for that timer.  This
leaves the jitter from the first three sources: the GPS, the PPS
capture hardware, and the system clock.   And this puts us down in the
100 ns range, with a worse case of up to about 1 µs.

So that's what using a timer to capture a PPS can provide.  Two orders
of magnitude decrease in jitter.  We can also see that if one isn't
using a timer, the jitter in how long an interrupt handler takes to
generate a timestamp totally dominates the jitter from the GPS, system
clock, and a timer module.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ppshist.png
Type: image/png
Size: 37099 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20200712/1edc4d1a/attachment.png>