On Fri, Oct 12, 2012 at 10:36 UTC, Jari Takkala <jtakk...@gmail.com> wrote: > I'm testing NTP in multicast mode, and have a question about the roundtrip > delay calculation. From my understanding, at the time of > association initialization multicast clients engage in a volley with the > server in order to authenticate the server, set the time, and calculate the > roundtrip delay. > > I've noticed that clients do not perform any additional roundtrip delay > calculations. I'm wondering why this occurs only once at initialization as > I think that a network topology change could alter the roundtrip delay, > thereby causing clients to be offset from the true time by the additional > delay. In certain WAN circuits for us a topology change could cause a route > to take up to 10's of milliseconds longer. > > Am I mistaken in that clients do not perform additional roundtrip delay > measurements? Would it not be sensible for clients to periodically poll the > server to establish if the RTT has changed?
Your analysis is correct, but the design priority for broadcast/multicast clients is to minimize server load, not maximize accuracy. > I concede that it sounds like unicast is the answer for us, particularly as > there would be the question of at what frequency would a client do > additional delay measurements, as time could still drift between delay > measurements. The problem I'm trying to solve is that I have a network of > stratum 1 timeservers located around the world, with thousands of > hosts synchronizing to them at a fairly frequent interval. I had the idea > that switching from unicast to multicast would reduce the queries at the > timeservers, thereby improving our accuracy in most cases. Use ntpdc -c iostats to sample some of your S1 servers over time and determine their peak and/or average queries per second. Unless they are seeing hundreds or thousands of queries per second, my guess is you're better off using unicast (or manycast, which operates as unicast after server discovery). If you are seeing substantial load on your S1s, you might consider an intermediate layer of S2 servers to handle the client load while minimizing traffic to the S1s -- there is very little difference in time service quality from S2s on the same LAN as their S1 sources. Cheers, Dave Hart _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions