[time-nuts] Best Chance GPS module
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
> 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
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
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
> 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