[time-nuts] Re: PPS latency? User vs kernel mode

[Javier Herrero]

Hello,

I have not tried with Raspberry (and would not...), but in order to 
avoid interrupt latencies and jitter, my approach, using a Zynq, is:

- To implement a counter in the FPGA for use as the Linux clock source, 
instead of the ARM timer
- Implement harware timestamping on the PPS, and generate the interrupt 
(and since I was there, I use an external clock source for the counter 
like the GPSO that gives also the PPS signal, instead of the usually 
crappy XO that drives the Zynq clocks)
- And then have a lot of fun convincing the kernel to use the FPGA 
counter as clock source, and converting raw PPS timestamp times to wall 
clock in the kernel, to be able to give a good timestamp value to ntp/chrony

I have implemented this approach both using a u-blox M8F (using the 
30.72MHz signal as source for the timer clock), and using a 10MHz GPSDO.

Best regards,

Javier, EA1CRB

On 12/12/21 22:55, Poul-Henning Kamp wrote:
> --------
>
> Interrupts are no longer hardware phenomena, but bus transactions
> which must lay claim to one or more busses, send a formatted message
> which is received by some kind of "interrupt prioritizer" which
> again, may or may not send another message on another kind of bus
> to the instruction sequencer in one or more CPU cores.
>
> Both of these message transmissions will very likely involve
> clock-domain-crossings.
>
> The good news is the per-interrupt overhead is lower, thanks to
> interrupts being 'gently woven into' the instruction stream, instead
> of hitting it with a sledgehammer.
>
> But the latency and jitter is literally all over the place...
>
> Fortunately a lot of "counter-module" hardware can be used
> to hardware-timestamp signals, even if the design does not
> exactly support it.
>
> For instance, the code I wrote for the Soekris 4501 uses two
> hardware counters:
>
> The first one, free-running, is the "timecounter" which the system
> clock is based on.
>
> The second one starts counting at the same rate as the first
> when the PPS signal comes in.
>
> By the time the CPU comes around to read both counters, it subtracts
> the second from the first, to figure out what time the hardware
> signal happened.
>