[ntp:questions] broadcast client

Bill Unruh unruh at physics.ubc.ca
Sat Nov 22 18:58:13 UTC 2008

On Sat, 22 Nov 2008, Danny Mayer wrote:

> Normally I would not respond to a 2 month old message but I need to
> correct some things here that were written.
> Unruh wrote:
>>>> 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.
> This is NOT the default behavior. minpoll defaults to 4 and maxpoll

minpoll defaults to 6 as far as I know.

> defaults to 10 and you should NOT change them unless you understand the
> discipline arguments and how these changes affect the discipline.

Sure, and I gave my reasons below.

>> Running on
>> 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.
> a) This is not correct. It has nothing to do with public servers. In
> addition I've conducted tests where I've fired 100's of packets per
> second and not even noticed any affect on other work on the target
> server. In the case of your own servers you won't notice the traffic in
> any event.

This is simply untrue that the large public servers would not notice if
everyone used minpoll 4. Many of the public servers get 10s of thousands
of queries a second and would be even higher if poll intervals were
shorter. Some were completely brought to their knees when the ntp on
routers were set to poll interval of 0 ( once per second) Minimizing
network traffic IS one of the  considerations.

> b) is also incorrect. The purpose of the backup is in the algorithms and
                            ^^^^^^^^^^^^^^^^^^^^^^  Not clear what this

> has to do with oversampling. In this case you are making your local
> clock less stable rather than more stable. More is not necessarily
> better and the sooner that people understand this the fewer problems
> that they will have.

  The allan minimum on a local
network is far less than David assumes in his model. The frequency shits
are dominated by temp variations which have hourly changes typically for
a computer which actually does work other than ntp. This means that the
long time intervals assumed by David are in fact inapporpriate for local
networks. Ie, short intervals are better especially if you have constant
  and fast connectivity.

>> I have no idea why you make the first claim. Yes, the rate will vary as the
>> network rates vary, but who cares. The purpose is to discipline the TIME,
>> not the rate.
> No. The purpose is to discipline both.

No, the purpose of ntp is to discipline the time and it does this by
disciplining the rate. The rate discipline is there to discipline the

>> And short polls discipline the time better.
> It doesn't.

Agrument by blatant assertion?

>> Rate discipline
>> is overrated because of the rate variations due to temperature changes
>> during the day anyway.
> No, it is not overrated unless you are oversampling like you are
> recommending.

Yes, I am advocating "oversampling". You are claiming that it is not a
good thing to do. Please defend that position with a bit of maths, not

Oversampling as you call it will discipline the time better especially
with the Markovian feedback filter ntp users. It will be worse at
disciplining the clock rate which will fluctuate more when you
oversample. Ie, oversampling will make int (t(T)-T)^2 dT smaller, where
T is the true time and t(T) is the clock time at true time T. It will
however make int (dt/dT-1)^2 dT larger. Now, for most people, it is the
time that is important, not dt/dT. If it is the rate that is important
to you ( ie you must know short intervals of time accurately -- ie to
better than 1PPM-- eg you are timing things that last one second and you
want to know them to 1usec) then use longer poll intervals with the ntp algorithm
( or use a different algorithm and different hardware).

> Danny

William G. Unruh   |  Canadian Institute for|     Tel: +1(604)822-3273
Physics&Astronomy  |     Advanced Research  |     Fax: +1(604)822-5324
UBC, Vancouver,BC  |   Program in Cosmology |     unruh at physics.ubc.ca
Canada V6T 1Z1     |      and Gravity       |  www.theory.physics.ubc.ca/

More information about the questions mailing list