Re: ntp problem in broadcastclients
On Wednesday, October 24, 2018 10:27:04 AM john doe wrote:
> On 10/24/2018 2:44 PM, Greg Wooledge wrote:
> > On Wed, Oct 24, 2018 at 08:22:49AM -0400, Gene Heskett wrote:
> >> I has this machine running ntp normally, and set to broadcast on the
> >> $local/24 network.
> >
> > I've never used NTP in "broadcast" mode.
> >
> > If it were me, I would simply use the normal configuration in which
> > each client system has the NTP server's hostname or IP address in
> > the /etc/ntp.conf file. If it turns out this "broadcast" thing
> > is the problem, then I'm not the right person to help.
> >
> > But...
> >
> >> Any clues of what else to check/change?
> >
> > Well, the obvious starting point would be "ntpq -p" on each system.
> > This is the new version of "ntptrace" which apparently has been
> > deprecated in order to make everyone's life harder.
> >
> > In addition to that, check the logs. If these are wheezy boxes (or
> > older) then you want /var/log/daemon.log*. If they're systemd boxes,
> > then you want (as root) journalctl -u ntp.
>
> In addition to the above, I would look at any kind of restriction
> (FW...) between the clients and the server.
I think that covers what I was going to say, but in an attempt to show off my
knowledge (or lack thereof) ;-)
As I understand it, NTP tries to get an approximate correct time for each
client machine by doing something like measuring the round trip time to the
server and back, then dividing by two, and applying that as a correction to
the broadcast time from the NTP server.
That was my understanding "back in the day" and I assume something similar is
still occurring.
On the other hand, it is hard to imagine that computers on your LAN have a
latency anywhere near 70 seconds in communication from your NTP "server" on
the same LAN (the one broadcasting the time).
Reply to: