[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