[ntp:questions] broadcast client

Unruh unruh-spam at physics.ubc.ca
Sun Sep 28 18:37:06 UTC 2008


David Woolley <david at ex.djwhome.demon.co.uk.invalid> writes:

>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:

It would be more helpful if he told us what he meant rather than us arguing
about what he could have meant. Yours is a possible interpretation.

>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.

As I understand his arguments this is based on some assumptions-- handling
ntp especially thousands or millions of clients, you do not want too
frequent a query-- smaller poll intervals are needed early on so that the
time required for phase lock is not too long, but longer intervals are
needed to minimize network impact-- Longer time intervals discipline the
frequency (drift) so that in case the closk goes offline, it still has a
good longer term baseline, because the drift discipline is inversely
proportional to the poll interval in the simple second order response
function he uses while the phase error is relatively constant. (This is not
true once the drift fluctuations are, over the poll interval, larger than
the phase fluctuations.)
Ie,, one of the critical "needs" is minimizing impact on the servers. That
is not there in this case. It is his own seerver which he can query as
often as desired.

So then rapid querying deos not do much about the phase errors but does
allow much more rapid adaptation to drift fluctuations, and reduces those.
It has worse long term behaviour as far as drift is concerned( ie it does a
worse job in figuring out what the long term drift is) but that is
irrelevalnt if you query often. If you switch from frequenct queries to
rare, then this will cause trouble.

Thus the standard defaults are based on minimizing impact on servers, and
minimizing errors when the connectivity fails for appreciable periods .


>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