[ntp:questions] broadcast client
David Woolley
david at ex.djwhome.demon.co.uk.invalid
Sun Sep 28 09:58:59 UTC 2008
Unruh wrote:
> David Woolley <david at ex.djwhome.demon.co.uk.invalid> writes:
>
>> rochertov at gmail.com wrote:
>>> Hello,
>>> I have a question regarding broadcast mode. I have 6 machines
>>> synchronizing with the same ntp server. That server uses uses a local
>>> ntp displined clock (we are looking into a GPS one). The machines are
>
>> "local ntp discipline" is a contradiction in terms. I think you mean a
>> completely undisciplined local clock configured to be the NTP reference
>> clock.
>
> No he is talking about an ntp server disciplined by a local hardware time
> source-- local not in the technical ntp sense but in the spatial sense.
>
What he says is:
> synchronizing with the same ntp server. That server uses uses a local
> ntp displined clock (we are looking into a GPS one). The machines are
> connected via 1 Gbps switch. The network is lightly loaded and I
> configured the clients as such
To me that says he is planning to use a physically local GPS clock, but
currently has no means of disciplining the server. If he had an
alternative means of disciplining the clock:
a) he probably wouldn't have mentioned the move to GPS;
b) it is a sufficiently unusual case, I would have expected him to have
provided details.
Moreover, looking at the passage as a whole, it looks to me as though he
has been reading typical responses on the newsgroup, and is trying to
anticipate the normal challenges he would get about the lack of a source
of discipline and the locking down of the polling rate.
>
>>> connected via 1 Gbps switch. The network is lightly loaded and I
>>> configured the clients as such
>>>
>>> server ntp minpoll 4 maxpoll 4 iburst
>
>> Dave Mills, please note, yet another non-believer in the NTP algorithms.
>
> What this has to do with not believing in the algorithm I have no idea. If
> ntp runs from a refclock that is EXACTLY the default behaviour. Running on
It's not running from a refclock, but over a network and Dave Mills
assumes that when running over a network one needs minpoll 6 maxpoll 10.
There are interesting questions about why reference clocks are treated
differently, but one guess would be that they are not subject to network
contention delays. In that case he is challenging the assumption that
network contention delays are still important in all configurations.
> a local private network where you are referencing your own server, that
> behaviour is also fine. The reason for the backup to long poll intervals is
> a) to save the public servers from flooding, and b)to discipline the local
> clock's drift rate in case there are long periods of disconnection from the
> net. If you have constant connection and it is your own server, neither of
> those apply, and short polling is better.
If he weren't challenging Dave Mills position, he would have assumed
that the errors came from relatively high frequency phase error
variations and relatively low frequency frequency variations. In that
case once you've passed the point where of maximum phase noise,
increasing the poll interval will not significantly degrade the phase
measurement until the frequency variations start to have an effect, but
it will continue to improve the frequency accuracy and the measurement
accuracy for time intervals.
Your observations suggest there are high frequency components in the
frequency variations, and, therefore, the cross over point is much lower
than NTP is built to assume. That then justifies a forced fast poll
rate (although in the case of maxpoll, only if the software fails to
find the right rate adaptively). If the min and maxpoll are being set
on that basis, he is, again, assuming that Dave Mills design assumptions
are wrong.
> ??? On a local network 20usec is more like the mean error, assuming a
> network that is not heavily loaded.
My impressions (although I haven't used a local clock on fast, quiet,
networks for a long time) is that that might be about right for the
error, but he is measuring offset, and my experience would suggest that
often >100 microseconds is more realistic.
More information about the questions
mailing list