[ntp:questions] Updates to Delay Calculation in Multicast Mode
hart at ntp.org
Fri Oct 12 16:19:49 UTC 2012
On Fri, Oct 12, 2012 at 10:36 UTC, Jari Takkala <jtakkala at 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
> 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.
More information about the questions