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

Vitezslav Samel vitezslav at samel.cz
Mon Oct 19 10:43:47 UTC 2020

On Mon, Oct 19, 2020 at 09:49:36AM +0200, Miroslav Lichvar wrote:
> 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.

  Any pointers/info how to use this in Linux?



More information about the questions mailing list