[ntp:questions] Advice about architecture

Charles Elliott elliott.ch at verizon.net
Thu Nov 10 15:14:18 UTC 2011


I don't understand why you are not recommending some sort of GPS device as
the primary time source for Marongiu's system.  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
milliseconds.  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.  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.

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.
See Meinberg Radio Clocks, Bad Pyrmont, Germany, http://www.meinberg.de.

Charles Elliott

> -----Original Message-----
> From: questions-bounces+elliott.ch=verizon.net at lists.ntp.org
> [mailto:questions-bounces+elliott.ch=verizon.net at lists.ntp.org] On
> Behalf Of Dave Hart
> Sent: Thursday, November 10, 2011 5:10 AM
> To: Marco Marongiu
> Cc: questions at lists.ntp.org
> Subject: Re: [ntp:questions] Advice about architecture
> 
> On Fri, Nov 4, 2011 at 13:04, Marco Marongiu <brontolinux at gmail.com>
> wrote:
> > Hi all
> >
> > I am going to revise the design I usually use for our synchronization
> > subnet. The plan is to take IPv6 in consideration, manycast, and to
> use
> > autokey. Anyway, before going any further, I'd like to ask you what
> you
> > think about how I _currently_ organize my synchronization subnets.
> 
> It seems pretty sound to me.  I don't personally have much experience
> with peered servers, so I'm curious if they seem to do what you hoped
> and expected when internet connectivity is interrupted.
> 
> > Normally, in each location I use four multicast servers with
> symmetric
> > keys. Each location has very small boundaries, both geographically
> and
> > network-wise: it could be a datacenter, or a building, with a limited
> > number of network switches/routers. In such an environment, network
> > variables such as delay and latency are usually quite stable, and I
> feel
> > that many of the downsides of using multicast are almost negligible.
> 
> I am of the opinion that if feasible, NTP manycast is a better choice
> than broadcast/multicast, with the same self-organizing benefit but
> without those presumed almost negligible downsides.  ntpd can easily
> handle hundreds of queries per second without degrading quality of
> service, so for me you would have to have an insanely large number of
> clients for the reduced server load of multicast compared to manycast
> to be a benefit.  For networks of tens or low hundreds of clients,
> fully-meshed designs with every client both a manycast server and
> manycast client and all participating in orphan mode, with a small
> subset configured with upstream sources, are self-organizing and
> reorganizing.  Don't get stuck in designing a hierarchy involving a
> few servers and many clients -- clients make good servers, too, when
> they're self-organizing.  Clients with relatively poorer clocks or
> higher root dispersion will automatically be avoided as manycast
> clients automatically cull servers that are not contributing for
> extended periods.
> 
> Cheers,
> Dave Hart
> _______________________________________________
> questions mailing list
> questions at lists.ntp.org
> http://lists.ntp.org/listinfo/questions



More information about the questions mailing list