[ntp:questions] Broadcast mode

Harlan Stenn stenn at ntp.org
Mon Sep 12 10:35:16 UTC 2016


Martin Burnicki writes:
> Hi,
> 
> Martin Townsend wrote:
> > Hi,
> > 
> > We have a closed network of embedded devices that we want to keep in
> > sync, the actual time is not important but the fact that they are all
> > on the same time is.  One device is always the master so this is the
> > device that we want the others to synchronise to.
> > 
> > Reading the documentation broadcast mode looks perfect.  I'm currently
> > trying it out with the following configuration:
> > 
> > # Broadcast Server
> > broadcast 192.168.2.255
> > ttl 1
> > 
> > server 127.127.1.0
> > fudge 127.127.1.0 stratum 14
> > 
> > ...
> > 
> > # Broadcast Client
> > broadcastclient
> > 
> > server 127.127.1.0
> > fudge 127.127.1.0 stratum 14
> > 
> > ...
> > 
> > 
> > I've seen what look like valid messages being exchanged using tcpdump
> > but haven't seen any evidence that the times are converging but I
> > haven't really left it long enough. In the meantime I have read this
> > link
> > http://www.ntp.org/ntpfaq/NTP-s-config-adv.htm#AEN3658
> > which seems to indicate that this setup is not possible.  So my question is
> > Is broadcast mode with LCL a non started and if so what is the best
> > method for a private network that you need to keep in sync?
> > 
> > I'm using the latest version 4.2.8p8, built using Yocto for an ARM cortex A
> 8.
> 
> Broadcast mode requires some kind of authentication by default, so the
> client know the broadcast packet has really been sent by the trusted
> server. Without authentication any node on the network could start
> sending broadcast packets with a wrong time, and the clients might
> follow that wrong time.
> 
> So you either have to configure authentication properly on the server
> *and* on each client, or you you have to disable authentication
> explicitly on each client.
> 
> The question still remains why you think broadcast mode is better than
> normal client / server mode. in broadcast mode the client is unable to
> determine and compensate the packet delay on the network, so the
> resulting accuracy is worse than with client / server mode.
> 
> Foe client / server mode you'd just need:
> 
> on the server:
> 
> server 127.127.1.0
> fudge 127.127.1.0 stratum 0

Martin, why do you recommend stratum 0 instead of leaving the default,
stratum 5?

> on each non-Windows client:
> 
> server aa.bb.cc.dd iburst
> 
> on each Windows client:
> 
> server aa.bb.cc.dd iburst minpoll 6 maxpoll 6
> 
> Of course you had to replace "aa.bb.cc.dd" by the real IP address of
> your server. "minpoll 6 maxpoll 6" avoid some limitations on Windows
> clients.
> 
> The stratum of the local clock (127.127.1.0) on the server should be
> fudged to 0 so the server is visible as stratum 1. If you fudge the
> local clock to 14 then the server will be stratum 15, which is only one
> level above "not available".
> 
> This is not accepted by some NTP implementations, and I'm not sure if
> ntpd as client would even accept a stratum 5 server, broadcast or not.

The default stratum for a local refclock should be just fine.
-- 
Harlan Stenn <stenn at ntp.org>
http://networktimefoundation.org - be a member!


More information about the questions mailing list