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
