[ntp:questions] Re: Using NTP in broadcast mode with no reverse link

Ben Gamsa ben at somanetworks.com
Mon Dec 1 05:25:08 UTC 2003


Dale Worley <worley at dragon.ariadne.com> wrote in message news:<878ylx95jz.fsf at netnews.comcast.net>...
> ben at somanetworks.com (Ben Gamsa) writes:
> > I'd like to configure it in a way that hard codes the one way
> > latency and completely avoids the initial burst-mode startup
> > exchanges (or any other exchanges that might occur later due to time
> > problems).
> 
> (I'm weak on this subject, but no one else has answered.)
> 
> I think that's what 'broadcastclient' *does*.  As long as you have no
> server/peer lines, NTP can't do an initial burst.  (And there's an
> option you can turn off to suppress the burst, anyway.)

I guess I failed to find the option to completely disable the initial
burst.  My problem is that although there is a reverse link, I'd much
rather it not be used for the initial burst, both because the one-way
estimate it will arrive at will likely be far worse than a hard-coded
constant, and because of the extra traffic such bursts will involve.
If there's an option to force the client to go directly to bclient mode,
and skip the initial client mode (and stay in bclient mode, even if it
at some point considers the server to be unreachable), that would be 
ideal.  From the code, it wasn't clear how it would react to the
broadcasts if it thinks it can't communicate with the server.

> 
> The biggest problem I forsee is that if the clock on a client is off
> too far, NTP may reject any broadcast packets it sees, and never sync
> the clock.  Though you may be able to adjust NTP or write a custom
> program to wait for a broadcast packet and directly force the local
> clock to that time.
> 
> Dale

As someone else already said, the -g option handles that problem, which
I'm already using.

    ben



More information about the questions mailing list