[ntp:questions] Advice about architecture

Dave Hart davehart at gmail.com
Thu Nov 10 10:10:30 UTC 2011

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.

Dave Hart

More information about the questions mailing list