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

John Ackermann N8UR jra at febo.com
Mon Oct 19 16:27:09 UTC 2020


Things have changed quite a bit in the GPS world lately.  u-blox makes a 
number of timing receivers that get to as good as +/-4 nanosecond RMS 
jitter (the ZED-F9T).  Even the cheaper units are in the <10 ns jitter 
range.  So as a practical matter, the GPS PPS noise is a lot less than 
the interrupt latency of most computers.

Absolute time accuracy is easy to 100 nanoseconds.  To get less than 
that, you need to account for things like the antenna and test 
connection cable lengths -- remember that 1 ns is 1 foot in free space. 
Getting <50 ns is certainly doable with a bit of care.  Even with a 
*lot* of care, and crazy things like temperature-controlled antennas, 
getting to better than 10 ns vs UTC(USNO) is very, very hard.

Also note that the timing grade receivers allow you to set a "0D" or 
"Timing" mode where you provide an accurate location and the receiver 
only has to solve for the time variable.  This can improve the 
accuracy/stability of the result over operating in normal "3D" mode.

Most timing users don't use augmentation like WAAS or differential GPS. 
When you provide a fixed station location, that takes care of the 
positioning and the augmentation doesn't provide any further help.

The ZED-F9T is also a dual frequency (L1 and L2) receiver which improves 
performance even more.  But it's not cheap -- the module is around $200 
in single quantity.  The u-blox NEO-M8T is the prior generation timing 
receiver which is still single frequency, but has all the other bells 
and whistles.  That module is $89 in single quantity.  You can buy 
evaluation boards with the modules installed for around $200 -- check 
Sparkfun or www.gnss.store.

There are a lot of lower cost units that can work pretty well, but most 
of them lack the 0D position mode capability, and often have more 
second-to-second jitter.  But for NTP purposes, those things are 
literally in the noise compared to the processor jitter.

John
----

On 10/19/20 9:03 AM, Charles Elliott wrote:
> Hello:
> 
>                  The original question was what realistic performance can one
> expect from GPS PPS. Based on some reading I did over the weekend here is a
> definitive answer:
> 
>   
> 
>                 The 2001 SPS (standard, civilian signal, GPS in the United
> States) timing standard was 40 ns with 30 ns accuracy commonly observed. (M
> & E, p. 49).
> 
>   
> 
>                  Time and distance are related with GPS (see M&E,  p. 23),
> and good differential GPS (DGPS) is supposed to yield approximately 10 times
> the distance accuracy of the above specification, which implies one should
> be able to achieve 3-4 ns accuracy with GPS timing. The FAA's Wide Area
> Augmentation System (WAAS) is supposed to produce 2 m accuracy throughout
> the United States. This would imply approximately 8 ns to 6 ns time
> accuracy. Of course, you need a recently manufactured chip to pick up DGPS
> and WAAS. In addition, most GPS chips require that commands be sent to them
> to activate the GPS and WAAS. These commands are available in recent NMEA
> manuals published by chip manufacturers that you can find by googling for
> them. The 15-year-old GPS chip that I own constantly slips into an out of
> DGPS mode, which implies that the command to activate DGPS must be resent to
> the GPS chip periodically.
> 
>   
> 
>                  The equation that the GPS chip solves every second has four
> unknowns: the receiver position in three dimensions and time. This implies
> that to solve this equation definitively four satellites must be in view.
> However if more than four satellites are in view the equation is
> over-determined and the fix is obtained by least-squares regression, which
> yields maximum likelihood predictors for the four variables. These
> predictors are much, much more accurate than the simple solution of the
> equation. A recent chip that picks up American GPS satellites, the Russian
> GLONASS satellites, and the European Galileo satellites should produce far
> better results than an older chip.  My $40 Alcatel model A503DL Android
> phone commonly claims to have 19 or more satellites in view.
> 
>   
> 
>                  The GPS fix changes as satellites slip into, or out of,
> view. Consequently one can observe jumps in time either forward or backward.
> Not to belabor the obvious, but time is monotonically increasing. So any
> jumps in time of more or less than about a positive second should be
> ignored.
> 
>   
> 
>                  The American GPS system has two new signals (L2C and L5)
> which will greatly improve accuracy when they are fully operational. They
> are being phased in as older satellites are replenished with new models.
> L2C first began to appear in 2005 and L5 in 2010. Both are available now,
> but in a pre-operational stage so that one uses them at their own risk. A
> summary of the signals and their availability appears here:
> https://www.gps.gov/systems/gps/modernization/civilsignals/.
> 
>   
> 
>                  The best published work on GPS accuracy and NTPD was done by
> David Taylor at www.satsignal.eu <http://www.satsignal.eu>  and appears
> here: https://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html
> <https://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html>  and elsewhere on the
> satsignal.eu website. David has found one GPS chip that appears to produce
> really remarkable results.
> 
>   
> 
>                  M&E = Misra, P. and P. Enge (2012). Global Positioning
> System: Signals, Measurements and Performance. Lincoln, Massachusetts, USA,
> Ganga-Jamuna Press.
> 
>                  
> 
> Charles Elliott
> 
>   
> 
>   
> 
> Original Message questions
> [mailto:questions-bounces+elliott.ch=comcast.net at lists.ntp.org] On Behalf Of
> Miroslav Lichvar
> Sent: Monday, October 19, 2020 3:50 AM
> To: questions at lists.ntp.org
> Subject: Re: [ntp:questions] Realistic Performance Expectation for GPS PPS
> fed ntpd jitter
> 
>   
> 
> 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.
> 
>   
> 
> --
> 
> Miroslav Lichvar
> 
>   
> 
> _______________________________________________
> 
> questions mailing list
> 
>   <mailto:questions at lists.ntp.org> questions at lists.ntp.org
> 
>   <http://lists.ntp.org/listinfo/questions>
> http://lists.ntp.org/listinfo/questions
> 
> _______________________________________________
> questions mailing list
> questions at lists.ntp.org
> http://lists.ntp.org/listinfo/questions
> 


More information about the questions mailing list