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
