[time-nuts] Best Chance GPS module

MLewis mlewis000 at rogers.com
Thu Dec 1 05:16:06 EST 2016


On 30/11/2016 4:23 PM, Gary E. Miller wrote:
> Yo MLewis!
>
> I suggest you take this over to NTPsec:devel at ntpsec.org, or
> on gpsd:gpsd-users at nongnu.org
Looks interesting. Thanks!




On 01/12/2016 1:51 AM, Chris Albertson wrote:
> First question:   How accurate does your local NTP server need to be?   If
> the answer is "a few tens of milliseconds" then you don't need GPS.  All yu
> need is a decent Internet connection.
Tens of milliseconds doesn't cut it.
Worst possible is +/- 10 ms. Should be +/- 5 ms or better. I'd be very 
happy with +/- 1 ms.
According to NTP, my computer lags, from 2 ms per minute to 16 ms per 
minute, depending on the processing load. This is causing my timed 
snapshotting of data to lag, hence it is wrong.
My approach had been to track the offset - without updating System Time 
- and apply that current offset to the System Time to get a time 
reasonably unmolested by the lag. I was thinking I was doing well, 
polling from a single host. But from Nov. 4, 2016, the reported offsets 
went nuts.

> Second.  NTP is a VERY light load and certainly does not need to run on a dedicated computer.

I'd been polling a single host, but finding comments on a draft of Best 
Current Practice (https://tools.ietf.org/html/draft-ietf-ntp-bcp-02), I 
went with polling six hosts, and promptly discovered just how variable 
and varying the reported offsets are; every poll the mix is different. I 
chose distant servers while testing, then chose closer hosts once setup, 
which cleaned it up considerably, usually, but variance in the reported 
offsets from these hosts range from 12 ms to 150 ms, occasionally 250 
ms. My best guess is this is due to the software timestamps getting 
aggravated results due to varying load (not NTP load) on my computer, 
along with variable response from my ISP. The straw that broke the 
camel's back was a recent graph of the hosts' reported offsets with 
their mean and a corrected mean: the graph looked like an ADHD child's 
rendering of a crocodile heading for orbit, either that or a coyote with 
a very very long and rather frizzy tail.

In any event, having my own dedicated NTP computer means all of the 
variables from varying loads on my computer are removed from NTP host 
polling. That's got to get a better result than I'm seeing from NTP on 
my computer. Then I can poll that machine as my own local host to my 
heart's content, Ethernet machine-to-machine with no internet in 
between. I understand that 1 ms precision between the two machines is 
expected.
Adding in GPS means I get GPS accuracy when available and have internet 
NTP hosts as backup in case GPS fails (and be polling hosts that aren't 
GPS).

That should allow me to get an offset with 1 ms precision anytime I need.

What I don't know, is if it is a good idea to have the internet polling 
NTP box receiving the PPS from the GPS or if I want another small box 
inbetween.

> About the GPS receiver.   Even the (within reason) worst GPS receiver with
> a partial view of the sky and some multiparty will by ODERS of MAGNITUDE
> more accurate then needed for running NTP. ... I'd say
> if yu can get the GPS to run at all it will be good enough for NTP.
Exactly. I'm not worried about the accuracy from a GPS receiver, their 
worst exceeds my needs - if they can track where I'm physically 
situated. Hence liking a timing GPS module with its ability to rest 
location tracking once it's got a fix, and a modern one for the best 
sensitivity (read as: likelihood of successful tracking).



More information about the time-nuts mailing list