Re: broadcast client
- From: Unruh <unruh-spam@xxxxxxxxxxxxxx>
- Date: Sun, 28 Sep 2008 18:37:06 GMT
David Woolley <david@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> writes:
Unruh wrote:
David Woolley <david@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> writes:What he says is:
rochertov@xxxxxxxxx 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.
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.
.
- Follow-Ups:
- Re: broadcast client
- From: rochertov
- Re: broadcast client
- References:
- broadcast client
- From: rochertov
- Re: broadcast client
- From: David Woolley
- Re: broadcast client
- From: Unruh
- Re: broadcast client
- From: David Woolley
- broadcast client
- Prev by Date: Re: NTP on LAN
- Next by Date: Re: broadcast client
- Previous by thread: Re: broadcast client
- Next by thread: Re: broadcast client
- Index(es):
Relevant Pages
|
