Yo MLewis!

On Wed, 30 Nov 2016 16:11:05 -0500
MLewis mlewis000@rogers.com wrote:

I suggest you take this over to NTPsec: devel@ntpsec.org, or
on gpsd: gpsd-users@nongnu.org

They are working on a HOWTO that does exactly what you want.

You can download a git copy of it:

https://gitlab.com/NTPsec/stratum-1-microserver-howto

I have 4 RasPis with various GPS attached, and an Orange Pi to add
soon.  Works great.

RGDS
GARY

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com  Tel:+1 541 382 8588

Hi

A few basics:

1. GPS receivers really can’t / don’t do a lot about multipath. The newer devices with a lot
   of correlators help a bit, but that’s about it. Simply put - newer is better.
2. Because of near the omnidirectional nature of GPS, antennas don’t do a lot for multipath. They
   can help a bit on low angle stuff, but that’s not going to be your problem.
3. Unless you can reasonably expect 4 sat’s in view at all time, don’t bother with setting up a GPS
   timing system. It will just make you angry with all the issues. A USB GPS on your PC will give you a
   pretty good idea of what you can or can’t pick up.
4. If the sole reason to do this is for NTP, consider simply setting up a local server and doing sync
   over your internet connection. Much less fuss ….

Bob

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.

Second.  NTP is a VERY light load and certainly does not need to run on a
dedicated computer.  Any mail server, web server or any computer that runs
24x7 can run NTP and you will not notice the extra load on the system.
And even in the case where you need GPS, one need just ONE computer.
Almost any computer is powerful enough and you only need 100 Bit Ethernet,
gigabit is not better for timing.

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.  The reason is that the BESTR
one can hope for with a near perfect NTP setup is a few micro seconds error
and even a quite poor GPS will do better than 100 nanoseconds.    I'd say
if yu can get the GPS to run at all it will be good enough for NTP.

One other thing:  Your GPS ABSOLUTELY MUST produce a one pulse per second
output.

If on the other hand your were trying to build a frequency standard or a
GPS controlled oscillator then you'd be worried about tons and tons of
details like you listed.  You literally just can't be good enough for
running a GPSDO.  But for NTP it is easy because even a run of the mill GPS
receiver is dramatically better than needed for NTP.

But take a serious look at your requirements.  I got into running NTP long
before therefore affordable GPS receivers.  In fact long before we all have
"always on" Internet connections and we all had dial-up phone modem.  So I
ran NTP over a phone modem and used that time standard to run an
astronomical telescope and was able to aim it at stars.  Many times your
requirements are not so hard and something simple works well.

Don't struggle getting the last nanosecond of accuracy out of a GPS when
NTP is only about to transfer millisecond level time over Ethernet.

On the other hand, if yu time stamping needs to be at the microsecond level
then the GPS must be physically connected to the computer doing the
stamping, yu can't transfer microseconds over an Ethernet and if you need
nanosecond level time stamps you can't get that in software

On Wed, Nov 30, 2016 at 1:11 PM, MLewis mlewis000@rogers.com wrote:

--

Chris Albertson
Redondo Beach, California

On 30/11/2016 4:23 PM, Gary E. Miller wrote:

Looks interesting. Thanks!

On 01/12/2016 1:51 AM, Chris Albertson wrote:

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.

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.

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).

HI

GPS depends on a line of sight view to the satellites involved. The time of flight
over this path is what gives you the navigation solution. The navigation solution
is something you must have before you can begin to get a timing solution.  A
GPS does indeed go to “no solution” before it gets bad enough to degrade NTP.
No solution does not help you much ….

Bob

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.

--

Chris Albertson
Redondo Beach, California

On Thu, Dec 1, 2016, at 09:01 AM, Chris Albertson wrote:

You don't actually need to have PTP-capable network gear to make PTP
work
reasonably well.

I have a small test environment with a Symmetricom S300-Rb PTP
grandmaster
distributing time to six Cisco UCS blades running FreeBSD. The S300 does
hardware timestamping, but the UCS blades do not. The network has a
Cisco
UCS fabric switch plus an Arista 7124S, neither of which support PTP
transparency. Works fine; I haven't measured it exhaustively, but
preliminary
data suggests that I am getting 2.5e-5 seconds of drift in the worst
case.

I've heard reports that full hardware timestamping and transparent
switching
can easily get you into the 1e-7 range, but I haven't tried that yet.
/gp