[time-nuts] Best Chance GPS module

Thu Dec 1 17:01:48 UTC 2016

OK, now I know what you need.   Millisecond level time on the data
processing machine.

Let's assume you were able to set up a local NTP server that runs off it's
own GPS reference clock.   That machine will have an internal clock running
at around 10 microsecond error, give or time, Or about 100x better then you
need.      The problem will be to transfer that time over Ethernet to the
data processing machine.     I'd say it should just work.  Ethernet is not
perfect but good enough for what you want.

I really doubt varying processing load is an issue with NTP.   Read the
code in the GPS reference clocks nd in the Linus PPS driver.  It is
designed in such a way that processing does not matter.   What happens is
the PPS causes an interrupt and inside the handler the nanosecond clock is
sampled and copied to memory.   The handler has something like 8 lines of
code and runs very fast.  It sets a flag saying "got a sample" and if the
user level NTP code read the data any time in the next second we are OK.
NTP in the normal mode never sets the clock's absolute time, it only
adjusts the RATE, so it can be late or slow with no problems.     This is
why I suggested using GPS on the data processing computer, a GPS referenced
NTP is not effected much by processing load.   The source of error is
"jitter" in the interrupt latency only and this is at the few microsecond
level.

The other thing you might look at is NOT using NTP but using PTP.   This
might be a better match to your needs but it requires that you replace all
your network gear with equipment that can make hardware time stamps on the
network packets.      PTP uses hardware stamps to get around the processing
load problem.  But so does the NTP, PPS reference clock both work well.
In short NTP is the best for transferring time over the Internet while PTP
is best at transferring time over a local network where you can specify the
make and model of every router and switch.

I don't think your measurements are measuring correctly.  To measure the
accuracy of an NTP server you need a local GPS referenced server and then
while logged into that, you look at jitter (not offsets) to your other NTP
servers.   Any offset is perfectly fine, that is simple the communications
delay and is accounted for by NTP.   The jitter is a measure of the
uncertainty and that is what yu need to minimize.    If you were looking at
offset, just don't do that.

I think you might still be able to skip the GPS and just use Internet
servers and still keep stamps within your requirements but you could only
be certain of that if you have a GPS referenced server.   And once you have
the GPS it would be nonsense to not use it for your time stamps.

I think your only problem is finding a GPS with PPS output that works at
your location.   Don't worry much more.  If it works and has PPS it is good
enough

You might have a "Plan B", in case no GPS receiver works.  Use some other
radio based time service.   There are Cell phone receivers that pull time
from cell towers.   They are receive-only so no need to pay for cell
service.   There is always WWV but that is REALLY hard to use for this
purpose

Finally because this is Time Nuts that is another very good solution.   Buy
one of those Rubidium clocks on eBay.   You can move the clock to a place
where GPS is available and calibrate the Rb clock then move the clock back
to your underground office where GPS is not available.  For your purpose it
"time better then 1 millisecond" the Rb clock will stay calibrated for a
LONG time.    You can measure the drift when GPS is available and swap out
Rb clocks as required.   These clocks are not so expensive.  $100 or so
maybe

OK last option if GPS is not available -- Locate the GPS referenced NTP
server on some nearby rooftop nd use POTs (phone wire) or some other data
link back to the office.  NTP can work just fine using IP over serial link.
 even at low baud rates.

>
> 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).
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/m
> ailman/listinfo/time-nuts
> and follow the instructions there.
>

-- 

Chris Albertson
Redondo Beach, California