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.
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...@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@lists.ntp.org
http://lists.ntp.org/listinfo/questions
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
