[ntp:questions] Realistic Performance Expectation for GPS PPS fed ntpd jitter

Miroslav Lichvar mlichvar at redhat.com
Mon Oct 19 07:49:36 UTC 2020


On Thu, Oct 15, 2020 at 07:52:06AM +0200, Juergen Perlinger wrote:
> Another thing that gets into the way are the energy saving strategies
> modern CPUs employ, like reducing the clock speed and distribute load
> over cores. So unless you nail down the IRQ to a certain core and
> prevent cores from going to full sleep, the interrupt rescheduling can
> add another few usecs. IRQ processing was never a high speed thing on
> x86 platforms to start with, and it never kept up with speed boost all
> other parts of the architecture got, AFAIK.

Setting the CPU to a fixed frequency (e.g. using the userspace
governor) can help a lot with the stability of timestamping, not just
of the PPS signal, but also received NTP packets.

> In short, your numbers look familiar, and I don't know how to improve
> the much without dedicated hardware. I'm dreaming of some FPGA hardware
> on a PCIe board at an affordable price...

Not an FPGA, but the Intel I210 costs about $50 and it has a nice
hardware clock with PPS input/output, which is well supported in
Linux. It's a NIC, so you can use the same clock for timestamping PPS
and NTP packets, avoiding any asymmetries on the PCIe bus between the
PPS-timestamping hardware, CPU, and the NIC, which allows you to make
an NTP server accurate to few tens of nanoseconds.

-- 
Miroslav Lichvar



More information about the questions mailing list