[ntp:questions] broadcast client

Unruh unruh-spam at physics.ubc.ca
Fri Sep 26 17:12:40 UTC 2008

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 

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.

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

>Rochertov, please note that this will increase your vulnerability to 
>short term network propagation delay variations, although it may help if 
>you are subject to temperature variations.  Note that NTP doesn't 
>correct the time on each poll but rather updates the frequency, and rate 
>of change of frequency.

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. And short polls discipline the time better. Rate discipline
is overrated because of the rate variations due to temperature changes
during the day anyway.

>> Howerver, I notice that two clients have a relatively large offset
>> from the ntp server (greater than 100 micro-seconds according to "ntpq

>Firstly, see other posts over the last month about the fact that offset 
>is not the same as error.  I would say that, for a suitable OS and 
>hardware, with negligible work load, 100 microseconds was a reasonable 
>90 percentile figure.  You should not expect to achieve it 100% of the time.

??? On a local network 20usec is more like the mean error, assuming a
network that is not heavily loaded. 

>What OS are you using?

>How do the offsets vary with time?  An offset with a constant sign would 
>be very weird and would indicate a serious problem.  To the extent that 
>the time discipline algorithm is good,

>> -p").  I considered setting the server into broadcast mode and
>> enabling broadcastclient on the clients to avoid 6 machines polling
>> the same server every 16 seconds.  I have two questions regarding
>> this.  What is the syntax for setting the frequency of broadcasts on
>> the server?  Also, how can I check the approximate time offset between

>I believe you can measure the "offset" the same way as with a named 
>server, although it will be an even worse measure of error, as it will 
>also include the effects of changes in network loading between the time 
>that the round trip time was calibrated and the time of the current 

Agreed. There is absolutely no advantage to broadcast for his situation

>For error, you can also use the same methods, probably using OS kernel 
>modifications to output exact phase information using a PCI or ISA 
>parallel port, or modem control line, and then using specialist hardware 
>to compare the timing between two systems.  I'd suggest outputting the 
>clock interrupt time this way, and outputting the difference between 
>tick time and a round number multiple of the nominal tick time via a 
>software channel.

> > the clients and the server?  Should I then peer each client with the
> > ntp server and rely on broadcast messages for time synchronization?

>Peering and broadcasting are different.

More information about the questions mailing list