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: [email protected] > [mailto:[email protected]] On > Behalf Of Dave Hart > Sent: Thursday, November 10, 2011 5:10 AM > To: Marco Marongiu > Cc: [email protected] > Subject: Re: [ntp:questions] Advice about architecture > > On Fri, Nov 4, 2011 at 13:04, Marco Marongiu <[email protected]> > 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 > [email protected] > http://lists.ntp.org/listinfo/questions _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
