[ntp:questions] Updates to Delay Calculation in Multicast Mode

Jari Takkala jtakkala at gmail.com
Fri Oct 12 10:36:59 UTC 2012


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!


More information about the questions mailing list