Hi, 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? 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. However, I thought I'd still clarify here that multicast clients don't do any additional RTT measurements once initialized. I certainly couldn't find anything in the documentation or code to suggest this happens. If someone could offer confirmation on this, or general advice on a multicast NTP setup, it would be much appreciated. Thanks! Jari _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
