[ntp:questions] Advice about architecture
davehart_gmail_exchange_tee at davehart.net
Thu Nov 10 18:28:43 UTC 2011
On Thu, Nov 10, 2011 at 15:14, Charles Elliott <elliott.ch at verizon.net> wrote:
> I don't understand why you are not recommending some sort of GPS device as
> the primary time source for Marongiu's system.
You seem to be assuming goals of Marco's design which he didn't
specify. There are a number of questions that could inform better
1) How much offset is acceptable between his systems and UTC?
2) How much offset is acceptable between any given pair of systems in
a single data center?
3) How much offset is acceptable between any given pair of systems in
different data centers?
The lack of such requirements is part of why I didn't respond
initially. When I did respond, I responded only to the issue he
raised, which was "what you think about how I _currently_ organize my
synchronization subnets?" You seem to be assuming goals he didn't
I did not advise against using a local reference clock, and you are
correct that he can achieve tighter sync both to UTC and between
machines by placing one or more quality reference clocks in each data
> When the WAN becomes busy,
> usually during the daylight hours, the offset becomes highly and negatively
> correlated with the network delay. Also, the jitter can easily rise to the
> 500s. I am not sure of the source of this error; it may be that the
> algorithm for computing the round-trip transit delay is in error, or the
> to-server and from-server transit times may not be symmetric, but in any
> case the error in the computer time can, and often is, in the 100s of
A continuously saturated link can cause hundreds of milliseconds or
even seconds of error in the apparent offset to a remote source
reached across the saturated link. This is inherent in the NTP
protocol and is not due to asymmetry of forward and return paths, it
is due to the increased variability in round trip times (jitter)
compared to a path transiting no congested links.
> I own three GPS devices now, and I don't yet have PPS
> installed, but nevertheless the GPS seems never to vary more than about ±40
> ms from true time, although without accessing the true time over the
> telephone or by radio it is impossible to tell for sure.
Performance of GPS without PPS is highly dependent on the specific
receiver/firmware combination as well as the method of interface to
the PC. The same GPS puck connected via USB will typically have much
higher jitter than one connected via a traditional serial port
(usually RS-232, sometimes RS-442). I would not assume your
experience is applicable to other GPSes and/or connections. Imagine
how far off a navigation GPS's position reports would be if the
receiver internally could not do better than 40 msec. Basically
useless for navigation -- so the issue is not the GPS receiver so much
as its output timing performance. Garmin GPS 18x LVC pucks replaced
the earlier GPS 18 LVC with a more sensitive receiver that aquires
faster and in more marginal situations (like inside a window facing
north), a great improvement for navigation use, but the 18x output
timing jitter is worse than the earlier 18, providing poorer time
service in absence of PPS. This archives of this list provide a
wealth of information on these workhorse affordable receivers (which
do support PPS in the LVC variety, but also require custom wiring).
> With inexpensive
> GPS devices, which I have, time does appear to vary about ±40 ms over the
> day as satellites come into and go out of view. But with stratum 1 network
> time sources over the WAN, time accuracy appears to vary wildly in the
> interval ±100 ms or more.
There are inexpensive options such as the Sure evaluation board
(around $30) and the GPS 18x LVC (around $60) for those willing and
able to solder the required connections, which is trickier with the
Sure due to the need to solder on the board as opposed to simply mess
with a cord terminated in bare wires for the LVC). Personally, I've
bought two GPS 18x LVCs from the same fellow who provides a nice
packaged solution with USB and DB-9 serial connectors, with the USB
cable providing power while serial and PPS are wired to the DB-9, for
less than $120 delivered in the US last I checked. See the list
archives for his web and email addresses.
> We should find out what Marongiu's time accuracy requirements are. If they
> are severe, then he should think about using WWV over the radio, PPS over
> the telephone, or an expensive GPS device as his primary time source, IMHO.
Expensive is relative. $50 to $120 in the US is expensive for some,
and that gets you PPS and small fractions of a millisecond offset to
> See Meinberg Radio Clocks, Bad Pyrmont, Germany, http://www.meinberg.de.
These are somewhat more expensive, from what I gather. Cursed be all
vendors who provide no hint of their prices until you submit yourself
to their sales, uh, people. I've never heard anything but praise
regarding the quality of Meinberg solutions, but like practically
every other vendor of time synchronization hardware, their prices are
invisible to those who choose not to ask for pricing. Make me an
offer, please, or I'll find someone who does, on ornery principle that
I don't care to spend my time contacting N vendors about M options
when I can throw something together with a junked PC and $120 or less
that gets me way under 1 msec. I'd rather do the integration work
myself than play pricing peek-a-boo, but then I'm doing this as a
hobby, not to solve a business problem. It's probably true that if I
have to ask the price, it will be higher than I'd be willing to pay.
More information about the questions