[ntp:questions] Realistic Performance Expectation for GPS PPS fed ntpd jitter
elliott.ch at comcast.net
Thu Oct 15 19:11:22 UTC 2020
> I'm dreaming of some FPGA hardware on a PCIe board at an affordable
Have you seen these? None are on a PCIe board, but they do have GPS, a
timing crystal, and a PPS signal.
LeoNTP Networked Time NTP Server; Price: 300.00GBP
GPSDO GPS Disciplined Oscillator Clock NTP Time Server
There are several on this page that range in price from $155 to $219 USD.
Right now I am seeing 1-4 usec jitter from a combination of a PPS signal
from an American-made GPS device by Time Machines and a Chinese device from
JinnUSR advertised as "Network Time Server NTP Server for GPS Beidou GLONASS
Galileo QZSS Desktop tpUS," that serves as the system clock and gives the
second. All this is with the serial PPS DLL supplied by Meinberg. I do
have the GPS antennas at the end of a ladder that stretches 1/2 way to the
second floor roof of the house. It is common to have 7-9 satellites in a
fix at one time, which hugely improves position and perhaps time accuracy.
Any success I have had with the GPS is due to Misra, P. and P. Enge (2012).
Global Positioning System: Signals, Measurements and Performance. Lincoln,
Massachusetts, USA, Ganga-Jamuna Press. Read a little bit, make a few
changes, and better performance results.
You might note that with the above GPS devices requiring 3-4 Watts, there is
no way that a PC is an economical time server over the long run.
[mailto:questions-bounces+elliott.ch=comcast.net at lists.ntp.org] On Behalf Of
Sent: Thursday, October 15, 2020 1:52 AM
To: questions at lists.ntp.org
Subject: Re: [ntp:questions] Realistic Performance Expectation for GPS PPS
fed ntpd jitter
On 10/7/20 8:45 PM, Andreas Mattheiss wrote:
> 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
> What do you think, is my 10 micro jitter within experience? While I am
> writing this I just realised a post from David Taylor
> (< <mailto:qgmgcu$2ad$1 at dont-email.me> qgmgcu$2ad$1 at dont-email.me>)
> remote refid st t when poll reach delay offset
> o127.127.22.1 .uPPS. 0 l - 16 377 0.000 0.026
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)
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
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...
questions mailing list
<mailto:questions at lists.ntp.org> questions at lists.ntp.org
More information about the questions