[ntp:questions] Re: NTP broadcastclient update times?
david at djwhome.demon.co.uk
Sat Oct 16 09:07:11 UTC 2004
In article <ckpgsd$dpd$1 at osl016lin.hda.hydro.com>,
Terje Mathisen <terje.mathisen at hda.hydro.com> wrote:
> W. D. wrote:
> > 14 Oct 01:29:55 ntpd: time reset +1.643005 s
> > 14 Oct 01:55:43 ntpd: time reset -1.314898 s
> > 14 Oct 02:18:12 ntpd: time reset +0.485238 s
> > 14 Oct 02:53:42 ntpd: time reset +0.638312 s
> 500 ppm, but the alternating +/- steps seems to be pointing towards some
> other problem.
> b) Some other process is setting or otherwise affecting the cpu clock.
Competing updates also tend to cause steps in the same direction. This
sort of backwards and forwards hopping is typically a consequence of
variable, asymmetric, propagation delays, which seems very consistent
with the long round trip times and the fact that the submitter volunteered
that those round trip times are dependent on what he is doing.
One thing that concerns me here is the 1.6 second step; if that is
possible at all without hopping to an unsynchronised server, or a hacked
maximum root distance parameter, it would require switching from one
extreme of asymmetry to the other. Most asymmetric cases are data
consumers, for whom all the excess delays are on the downlink side.
He has far too many servers, and they are far too near the root for the
quality of internet connection he has. If he can't improve the quality,
he needs to reduce the number of servers and go to higher stratums
(because he is wasting the time of the stratum one servers, because he
cannot take advantage of their low root distances). If his ISP is good,
other than for the extreme propagation delays, he should be using just
their own provided NTP servers (these often exist, but are too technical
for the marketing department, so can be difficult to find out about).
(If the ISP is downstream of the bottlenecks and good, they will be
stratum 1 themselves!)
Otherwise, if time is critical, he needs some form of radio clock, or he
could try enabling huff&puff, or, with a recompile, setting MAX_DISTANCE
(?) just large enough to accept responses when the routes to the servers
aren't busy. (Actually, all you need is that the maximum root
distance is small enough that an update that is outside the minumum
delay by less than the step threshold is rejected - there are factors of
two involved in parts of the calculation, which I don't have time to
check at the moment. That should avoid stepping, even if tighter limits
are more stable.)
Covering an other answer in the thread. Signals in cables and optical
fibres propagate slightly slower than light, typically 2/3rd of the
speed for coaxial metal cables. Also, cable routes are unlikely to be
great circles between the extreme end points.
I did notice a hint that there was dual homing here (front door and
backdoor delay times). If there is dual homing, servers should be chosen
so as to achieve diversity across the two paths.
More information about the questions