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

Juergen Perlinger perlinger at nwtime.org
Thu Oct 15 19:46:52 UTC 2020

Hello Matt,

On 10/15/20 7:24 PM, Matt Corallo wrote:
> I was wondering about this too, so sat down and patched kernel to pull
> timestamps right after the interrupt fires and then decide later if it
> was because of DCD change (passing the timestamp through the dcd_change
> callback, its a pretty trivial patch). It cut the jitter down some (a
> few us, maybe) and killed some peaks, but clearly wasn't the source of
> most of the jitter here, at least on an embedded AMD box with other
> things to do between interrupts and a relatively poor system clock. I do
> already get better than 10us jitter, however, closer to maybe 5.

IMHO you won't get much better on a PC. 5µs is probably very close to
the IRQ response jitter. And an ordinary rs232 level shifter for the PPS
signal adds probably another µsec or two to the jitter -- high-quality
PPS signal distribution/transmission needs coax cable and analog line
drivers with impedance matching. I'm not nerdy enough to attempt this :)
But then, even a very good PPS line does not help without a hardware
counter capture register, because the IRQ response delay will be the
major contribution to the jitter.

But if you could share your UART code mods, that would make an
interesting reading. If I only had more time...


> Matt
> On 10/15/20 1:52 AM, Juergen Perlinger wrote:
>> On 10/7/20 8:45 PM, Andreas Mattheiss wrote:
>>> Hello,
>>> I wonder what's a realistic ballpark for the jitter I can expect when
>>> feeding a GPS PPS into ntpd?
>>> My setup is: a cheap u-blox NEO6M has its PPS output connected to a
>>> MAX232
>>> level shifter, connected to a true serial port on my desktop PC. I
>>> use it
>>> at the same time for daily work, so no designated ntp server. The GPS
>>> antenna is sitting inside, close to the window, with a building
>>> opposite -
>>> suboptimal view of the sky. I do feed RTMS corrections to the GPS though
>>> (ionospheric corrections etc.). The GPS is set to "stationary" mode, so
>>> it's probably set up as good as it gets.
>>> The jitter values I get do, sorry, jitter. I guess it's a lot to do with
>>> the poor view to the sky, mainly. PPS from GPS is claimed to be accurate
>>> to say 10's of ns; my jiitter values are around 10 micro s
>>> approximately,
>>> on avarege, for a well settled system set up as described. They do zoom
>>> up, occasionally, to 60 micro s though. I would assume that it's
>>> unrealistic to expect ns accuracy from ntpd on a non-designated system.
>>> What do you think, is my 10 micro jitter within experience? While I am
>>> writing this I just realised a post from David Taylor
>>> (<qgmgcu$2ad$1 at dont-email.me>) showing
>>>        remote           refid      st t when poll reach   delay   offset
>>> jitter
>>> ==============================================================================
>>> o127.127.22.1    .uPPS.           0 l    -   16  377    0.000    0.026
>>> 0.013
>> That's quite close to what I get -- either with a GPS18xLVC, or a
>> NEO-M8T (also homegrown, with a MAX-3232 TTL<->RS232 shifter)
>> I had better numbers (half the jitter) with my old Phenom-II box, but
>> with the XEON board I'm running now I see jitter in the 10usec range.
>> With both receivers active at the same time, I have a higher jitter --
>> clearly interrupt collision, and the jitter occasionally bumps up to
>> 20..30 usec, and the offset between the receivers (which is ~20usec)
>> reverses then.
>> I looked into the UART code of the Linux kernel (not _too_ deep) but
>> it's clear that the handling of the DCD signal change and the assigning
>> of time stamps to a change event is not optimal. The time stamp is not
>> assigned ASAP (as it is done in the line discipline), and thanks to the
>> IRQ sharing and status register poll loop there _has_ to be some delay.
>> Funny enough, with an Arduino I can create time stamps much more
>> reliable -- when I use a hardware counter with a latch-strobe signal.
>> (Here the IRQ is created _after_ the counter was value was stored in a
>> capture register!) Unfortunately, such a stratagem is not an option with
>> a PC...
>> 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.
>> 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...
>> Cheers,
>>     Pearly
>> _______________________________________________
>> questions mailing list
>> questions at lists.ntp.org
>> http://lists.ntp.org/listinfo/questions

More information about the questions mailing list