Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #201586 > unrolled thread

ntp problem in broadcastclients

Back to article view | Back to linux.debian.user

Contents

  ntp problem in broadcastclients Gene Heskett <gheskett@shentel.net> - 2018-10-24 14:30 +0200
    Re: ntp problem in broadcastclients Greg Wooledge <wooledg@eeg.ccf.org> - 2018-10-24 14:50 +0200
      Re: ntp problem in broadcastclients john doe <johndoe65534@mail.com> - 2018-10-24 16:30 +0200
        Re: ntp problem in broadcastclients rhkramer@gmail.com - 2018-10-24 17:10 +0200
          Re: ntp problem in broadcastclients Gene Heskett <gheskett@shentel.net> - 2018-10-25 00:30 +0200
            Re: ntp problem in broadcastclients rhkramer@gmail.com - 2018-10-25 01:20 +0200
              Re: ntp problem in broadcastclients rhkramer@gmail.com - 2018-10-25 01:20 +0200
        Re: ntp problem in broadcastclients Gene Heskett <gheskett@shentel.net> - 2018-10-25 00:30 +0200
          Re: ntp problem in broadcastclients Greg Wooledge <wooledg@eeg.ccf.org> - 2018-10-25 14:30 +0200
            Re: ntp problem in broadcastclients Curt <curty@free.fr> - 2018-10-25 15:40 +0200
              Re: ntp problem in broadcastclients Gene Heskett <gheskett@shentel.net> - 2018-10-25 20:10 +0200
                Re: ntp problem in broadcastclients Curt <curty@free.fr> - 2018-10-25 20:20 +0200
                  Re: ntp problem in broadcastclients Gene Heskett <gheskett@shentel.net> - 2018-10-25 22:50 +0200
                    Re: ntp problem in broadcastclients Greg Wooledge <wooledg@eeg.ccf.org> - 2018-10-25 23:00 +0200
                      Re: ntp problem in broadcastclients Gene Heskett <gheskett@shentel.net> - 2018-10-25 23:40 +0200
                        Re: ntp problem in broadcastclients Greg Wooledge <wooledg@eeg.ccf.org> - 2018-10-26 14:30 +0200
                          Re: ntp problem in broadcastclients Gene Heskett <gheskett@shentel.net> - 2018-10-26 15:40 +0200
                            Re: ntp problem in broadcastclients Greg Wooledge <wooledg@eeg.ccf.org> - 2018-10-26 16:00 +0200
                              Re: ntp problem in broadcastclients Gene Heskett <gheskett@shentel.net> - 2018-10-26 16:40 +0200
                        Re: ntp problem in broadcastclients Curt <curty@free.fr> - 2018-10-26 15:10 +0200
                          Re: ntp problem in broadcastclients Gene Heskett <gheskett@shentel.net> - 2018-10-26 15:50 +0200
                            Re: ntp problem in broadcastclients Michael Stone <mstone@debian.org> - 2018-10-26 16:30 +0200

Page 1 of 2  [1] 2  Next page →

#201586 — ntp problem in broadcastclients

I has this machine running ntp normally, and set to broadcast on the 
$local/24 network.

I have 6 other machines on this local network, but only 2 are staying 
with this machine timewise.

Does anyone have a clue why the other 4 are not, atm up to 35 seconds 
diff between them?  They all have this at the bottom of 
their /etc/ntp.conf:

disable auth
broadcastclient

No server entries on any of those, and this machine uses the debian pool 
as servers, and is set to broadcast to $local network on .255.

Any clues of what else to check/change?

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [next] | [standalone]

#201589

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.

[toc] | [prev] | [next] | [standalone]

#201591

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.

-- 
John Doe

[toc] | [prev] | [next] | [standalone]

#201594

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

[toc] | [prev] | [next] | [standalone]

#201613

On Wednesday 24 October 2018 11:07:05 rhkramer@gmail.com wrote:

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

Standard pings are in the 1 millisecond range.


-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#201614

On Wednesday, October 24, 2018 06:25:46 PM Gene Heskett wrote:
> On Wednesday 24 October 2018 11:07:05 rhkramer@gmail.com wrote:
> > 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).
> 
> Standard pings are in the 1 millisecond range.

Not the problem, for sure!

[toc] | [prev] | [next] | [standalone]

#201615

On Wednesday, October 24, 2018 07:10:00 PM rhkramer@gmail.com wrote:
> On Wednesday, October 24, 2018 06:25:46 PM Gene Heskett wrote:
> > On Wednesday 24 October 2018 11:07:05 rhkramer@gmail.com wrote:
> > > 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).
> > 
> > Standard pings are in the 1 millisecond range.
> 
> Not the problem, for sure!

Just a further thought, along similar line:

I vaguely have the impression (from posts you've made in the past) that you do 
things to make the LAN fast (for your CNC stuff) like use static IPs, and 
probably use those IPs rather than any names that have to be resolved, so I 
doubt that is a problem -- I guess I just mentioned it for posterity.

[toc] | [prev] | [next] | [standalone]

#201612

On Wednesday 24 October 2018 10:27:04 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.
The idea is to reduce the loading of 7 machines all banging one the level 
1 and 2 servers by designating one machine to bang of the debian pool, 
and then broadcast it on the local 192.169.xx.xx net so all the others 
stay within a millisecond of this machine.
2 machines report:
pi@picnc:/etc $ ntpq -p
No association ID's returned

One is keeping perfect time, the otheris off about 35 seconds, eveb after 
a warm reboot.
All the other machines show:
gene@sheldon:~$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  
jitter
==============================================================================
*coyote.coyote.d 65.223.27.156    2 u  387  512  377    0.137   -2.334   
0.667

Or very similar, One machine, an armhrpi-3b an armhf running jessie, 
makes me be root before ntpq -p will return good data.

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

I see you've noticed. I look at doing away with ntpdate with a semi 
juandiced viewpoint.

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

Firewall? whuzat?  I'm behind dd-wrt and all the radios are off to keep 
out the neighbors cell phones. firewall by shutting out the outside 
world IOW.

daemon.log.1 looks normal and reports its listening on eth0. daemon.log 
was rotated this morning and was empty until I did a warm reboot half an 
hour ago. And after the reboot its still 25 seconds slow.

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#201620

On Wed, Oct 24, 2018 at 06:23:49PM -0400, Gene Heskett wrote:
> The idea is to reduce the loading of 7 machines all banging one the level 
> 1 and 2 servers by designating one machine to bang of the debian pool, 
> and then broadcast it on the local 192.169.xx.xx net so all the others 
> stay within a millisecond of this machine.

Well yeah, of course, but you don't need "broadcast" for that.

Here at work, I chose three of my servers to act as the local NTP sources
for all of the other servers and workstations.  In our local DNS, I created
records to point to those machines as ntp1, ntp2 and ntp3.  (They also have
other names besides these.  These are just their NTP names.)

On ntp1, one of the local "servers", the /etc/ntp.conf file has:

pool 0.debian.pool.ntp.org iburst
pool 1.debian.pool.ntp.org iburst
pool 2.debian.pool.ntp.org iburst
pool 3.debian.pool.ntp.org iburst

Ntp2 and ntp3 have the same thing, or at least they should.

On my workstation, those lines are commented out, and I added:

server ntp1.eeg.ccf.org
server ntp2.eeg.ccf.org
server ntp3.eeg.ccf.org

This is how a "normal" (in my experience) LAN handles NTP.  Yes,
there's manual configuration of each machine, but I don't find that to
be a burden.  It's just those crazy kids these days that think everything
has to be done with multiple layers of Rube Goldberg devices.

> 2 machines report:
> pi@picnc:/etc $ ntpq -p
> No association ID's returned

I've literally never seen such a message before.  I googled it, and there
are definitely results that look relevant.  After adding "broadcast" to
the search terms, I came up with this result:

http://lists.ntp.org/pipermail/questions/2014-December/039401.html

Looks like a good starting point for your "broadcast" configuration.
I hope this helps.

[toc] | [prev] | [next] | [standalone]

#201622

On 2018-10-25, Greg Wooledge <wooledg@eeg.ccf.org> wrote:

>> 2 machines report:
>> pi@picnc:/etc $ ntpq -p
>> No association ID's returned
>
> I've literally never seen such a message before.  I googled it, and there
> are definitely results that look relevant.  After adding "broadcast" to
> the search terms, I came up with this result:

I saw this:

https://wiki.debian.org/NTP

 Troubleshooting

  If you run ntpq -p and you get
  
  No association ID's returned

 Run

 dpkg-reconfigure ntp

Seems kind of too easy and rather short on the explicit details, though.

> http://lists.ntp.org/pipermail/questions/2014-December/039401.html
>
> Looks like a good starting point for your "broadcast" configuration.
> I hope this helps.
>
x>


-- 
"Now she understood that Anna could not have been in lilac, and that her charm
was just that she always stood out against her attire, that her dress could
never be noticeable on her." Leo Tolstoy, Anna Karenina 

[toc] | [prev] | [next] | [standalone]

#201628

On Thursday 25 October 2018 09:32:08 Curt wrote:

> On 2018-10-25, Greg Wooledge <wooledg@eeg.ccf.org> wrote:
> >> 2 machines report:
> >> pi@picnc:/etc $ ntpq -p
> >> No association ID's returned
> >
> > I've literally never seen such a message before.  I googled it, and
> > there are definitely results that look relevant.  After adding
> > "broadcast" to the search terms, I came up with this result:
>
> I saw this:
>
> https://wiki.debian.org/NTP
>
>  Troubleshooting
>
>   If you run ntpq -p and you get
>
>   No association ID's returned
>
>  Run
>
>  dpkg-reconfigure ntp
>
> Seems kind of too easy and rather short on the explicit details,
> though.

not to belabor the point, but it also didn't work.  Sigh.

> > http://lists.ntp.org/pipermail/questions/2014-December/039401.html
> >
I'll look at that after I had a nap, been up since about 4ish.

> > Looks like a good starting point for your "broadcast" configuration.
> > I hope this helps.
>
> x>



-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#201629

On 2018-10-25, Gene Heskett <gheskett@shentel.net> wrote:
> On Thursday 25 October 2018 09:32:08 Curt wrote:
>
>> On 2018-10-25, Greg Wooledge <wooledg@eeg.ccf.org> wrote:
>> >> 2 machines report:
>> >> pi@picnc:/etc $ ntpq -p
>> >> No association ID's returned
>> >
>> > I've literally never seen such a message before.  I googled it, and
>> > there are definitely results that look relevant.  After adding
>> > "broadcast" to the search terms, I came up with this result:
>>
>> I saw this:
>>
>> https://wiki.debian.org/NTP
>>
>>  Troubleshooting
>>
>>   If you run ntpq -p and you get
>>
>>   No association ID's returned
>>
>>  Run
>>
>>  dpkg-reconfigure ntp
>>
>> Seems kind of too easy and rather short on the explicit details,
>> though.
>
> not to belabor the point, but it also didn't work.  Sigh.

That too.

>> > http://lists.ntp.org/pipermail/questions/2014-December/039401.html
>> >
> I'll look at that after I had a nap, been up since about 4ish.
>
>> > Looks like a good starting point for your "broadcast" configuration.
>> > I hope this helps.
>>
>> x>
>
>
>


-- 
"Now she understood that Anna could not have been in lilac, and that her charm
was just that she always stood out against her attire, that her dress could
never be noticeable on her." Leo Tolstoy, Anna Karenina 

[toc] | [prev] | [next] | [standalone]

#201645

On Thursday 25 October 2018 14:08:47 Curt wrote:

> On 2018-10-25, Gene Heskett <gheskett@shentel.net> wrote:
> > On Thursday 25 October 2018 09:32:08 Curt wrote:
> >> On 2018-10-25, Greg Wooledge <wooledg@eeg.ccf.org> wrote:
> >> >> 2 machines report:
> >> >> pi@picnc:/etc $ ntpq -p
> >> >> No association ID's returned
> >> >
> >> > I've literally never seen such a message before.  I googled it,
> >> > and there are definitely results that look relevant.  After
> >> > adding "broadcast" to the search terms, I came up with this
> >> > result:
> >>
> >> I saw this:
> >>
> >> https://wiki.debian.org/NTP
> >>
> >>  Troubleshooting
> >>
> >>   If you run ntpq -p and you get
> >>
> >>   No association ID's returned
> >>
> >>  Run
> >>
> >>  dpkg-reconfigure ntp
> >>
> >> Seems kind of too easy and rather short on the explicit details,
> >> though.
> >
> > not to belabor the point, but it also didn't work.  Sigh.
>
> That too.
>
> >> > http://lists.ntp.org/pipermail/questions/2014-December/039401.htm
> >> >l

This link indicated that I also needed a server entry in the ntp.conf files.
Added that, and restarted ntp, and everything now has the proper response to
an ntpq -p query. And its all in the same second for the individual date command.

I think I'll quit while I'm ahead. :)

I added the router to the server list for this machine and get this for an ntpq -p:
    remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 router.coyote.d .INIT.          16 u    -  512    0    0.000    0.000   0.000
-ip7.nsg.sbbsnet 64.113.44.54     2 u   31   64   17   43.611    5.083   2.148
+142.147.92.5.st 216.218.192.202  2 u   37   64  377   82.436   -3.643   1.587
*dfw1.m-d.net    204.9.54.119     2 u   99   64  376   49.024   -0.327   1.700
+12.167.151.2    198.148.79.210   3 u   31   64  377   15.694    0.584   2.247
 192.168.71.255  .BCST.          16 u    -   64    0    0.000    0.000   0.000

And the daemon.log now says:
Oct 25 16:16:04 coyote ntpd[5026]: ntpd exiting on signal 15
Oct 25 16:16:06 coyote ntpd[2518]: ntpd 4.2.6p5@1.2349-o Fri Jul 22 18:00:30 UTC 2016 (1)
Oct 25 16:16:06 coyote ntpd[2519]: proto: precision = 0.274 usec
Oct 25 16:16:06 coyote ntpd[2519]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
Oct 25 16:16:06 coyote ntpd[2519]: Listen and drop on 1 v6wildcard :: UDP 123
Oct 25 16:16:06 coyote ntpd[2519]: Listen normally on 2 lo 127.0.0.1 UDP 123
Oct 25 16:16:06 coyote ntpd[2519]: Listen normally on 3 eth0 192.168.71.3 UDP 123
Oct 25 16:16:06 coyote ntpd[2519]: peers refreshed
Oct 25 16:16:06 coyote ntpd[2519]: Listening on routing socket on fd #20 for interface updates
 
Does that all look legit?

> > I'll look at that after I had a nap, been up since about 4ish.

Thanks all.

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#201648

On Thu, Oct 25, 2018 at 04:40:46PM -0400, Gene Heskett wrote:
> I added the router to the server list for this machine and get this for an ntpq -p:
>     remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
>  router.coyote.d .INIT.          16 u    -  512    0    0.000    0.000   0.000
> -ip7.nsg.sbbsnet 64.113.44.54     2 u   31   64   17   43.611    5.083   2.148
> +142.147.92.5.st 216.218.192.202  2 u   37   64  377   82.436   -3.643   1.587
> *dfw1.m-d.net    204.9.54.119     2 u   99   64  376   49.024   -0.327   1.700
> +12.167.151.2    198.148.79.210   3 u   31   64  377   15.694    0.584   2.247
>  192.168.71.255  .BCST.          16 u    -   64    0    0.000    0.000   0.000

The first line (router.coyote.d, which I presume is your router)
is showing stratum 16, which means it does not consider itself to be
a valid time source yet.  This could be because you haven't given it
enough time to stabilize (i.e. you just restarted it), or because it
can't actually contact any time servers in order to synchronize at all.

If it remains "st 16" for more than a few minutes, then something is
probably wrong.

Meanwhile, this system is getting valid time synchronization from four
other sources (three of them stratum 2, one stratum 3).  Your offset
values look good (the offset is shown in milliseconds, so you are within
about 5 milliseconds of all your valid sources).

[toc] | [prev] | [next] | [standalone]

#201649

On Thursday 25 October 2018 16:50:11 Greg Wooledge wrote:

> On Thu, Oct 25, 2018 at 04:40:46PM -0400, Gene Heskett wrote:
> > I added the router to the server list for this machine and get this
> > for an ntpq -p: remote           refid      st t when poll reach  
> > delay   offset  jitter
> > ====================================================================
> >========== router.coyote.d .INIT.          16 u    -  512    0   
> > 0.000    0.000   0.000 -ip7.nsg.sbbsnet 64.113.44.54     2 u   31  
> > 64   17   43.611    5.083   2.148 +142.147.92.5.st 216.218.192.202 
> > 2 u   37   64  377   82.436   -3.643   1.587 *dfw1.m-d.net   
> > 204.9.54.119     2 u   99   64  376   49.024   -0.327   1.700
> > +12.167.151.2    198.148.79.210   3 u   31   64  377   15.694   
> > 0.584   2.247 192.168.71.255  .BCST.          16 u    -   64    0   
> > 0.000    0.000   0.000
>
> The first line (router.coyote.d, which I presume is your router)
> is showing stratum 16, which means it does not consider itself to be
> a valid time source yet. 

I wondered about that since I couldn't find a place in the  recent dd-wrt to enable broadcasting. So the last best step is to remove that ntp.conf 
entry, and either just leave the router to its own resources, or even change its server setting to this machine..

> This could be because you haven't given it 
> enough time to stabilize (i.e. you just restarted it), or because it
> can't actually contact any time servers in order to synchronize at
> all.
>
> If it remains "st 16" for more than a few minutes, then something is
> probably wrong.

I put the router back on pool.ntp.org, but had to reboot it to take effect.

Now this machine shows for ntpq -p:
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+159.203.158.197 45.33.103.94     3 u   59   64    3   19.551   -1.356  61.116
*tick.mdacore.ne 130.207.244.240  2 u   61   64    3   30.488   -2.042   3.042
-ntp3.junkemailf 216.218.254.202  2 u   59   64    3   82.196   -7.491   2.306
+208.76.53.137   216.218.254.202  2 u   64   64    3   40.852   -2.476   0.889
 192.168.71.255  .BCST.          16 u    -   64    0    0.000    0.000   0.000

But should the .BCST. be a 16 ?? Or is that just the nature of the beast?
>
> Meanwhile, this system is getting valid time synchronization from four
> other sources (three of them stratum 2, one stratum 3).  Your offset
> values look good (the offset is shown in milliseconds, so you are
> within about 5 milliseconds of all your valid sources).

Thanks Greg.

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#201671

On Thu, Oct 25, 2018 at 05:36:21PM -0400, Gene Heskett wrote:
> I put the router back on pool.ntp.org, but had to reboot it to take effect.
> 
> Now this machine shows for ntpq -p:
>      remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
> +159.203.158.197 45.33.103.94     3 u   59   64    3   19.551   -1.356  61.116
> *tick.mdacore.ne 130.207.244.240  2 u   61   64    3   30.488   -2.042   3.042
> -ntp3.junkemailf 216.218.254.202  2 u   59   64    3   82.196   -7.491   2.306
> +208.76.53.137   216.218.254.202  2 u   64   64    3   40.852   -2.476   0.889
>  192.168.71.255  .BCST.          16 u    -   64    0    0.000    0.000   0.000
> 
> But should the .BCST. be a 16 ?? Or is that just the nature of the beast?

According to <http://doc.ntp.org/4.2.2/debug.html>, BCST means "The
association belongs to a broadcast server."  And unfortunately, as I
mentioned before, I've never used NTP in broadcast mode.  So at this
point you're officially beyond my knowledge level.

[toc] | [prev] | [next] | [standalone]

#201675

On Friday 26 October 2018 08:26:47 Greg Wooledge wrote:

> On Thu, Oct 25, 2018 at 05:36:21PM -0400, Gene Heskett wrote:
> > I put the router back on pool.ntp.org, but had to reboot it to take
> > effect.
> >
> > Now this machine shows for ntpq -p:
> >      remote           refid      st t when poll reach   delay  
> > offset  jitter
> > ====================================================================
> >========== +159.203.158.197 45.33.103.94     3 u   59   64    3  
> > 19.551   -1.356  61.116 *tick.mdacore.ne 130.207.244.240  2 u   61  
> > 64    3   30.488   -2.042   3.042 -ntp3.junkemailf 216.218.254.202 
> > 2 u   59   64    3   82.196   -7.491   2.306 +208.76.53.137  
> > 216.218.254.202  2 u   64   64    3   40.852   -2.476   0.889
> > 192.168.71.255  .BCST.          16 u    -   64    0    0.000   
> > 0.000   0.000
> >
> > But should the .BCST. be a 16 ?? Or is that just the nature of the
> > beast?
>
> According to <http://doc.ntp.org/4.2.2/debug.html>, BCST means "The
> association belongs to a broadcast server."  And unfortunately, as I
> mentioned before, I've never used NTP in broadcast mode.  So at this
> point you're officially beyond my knowledge level.

Well, with all the clients now reporting this machine as a stratum 3 and 
fractions of a millisecond for an ntpq -p, and this machine reporting 5 
servers and  one BCST at a st=16, and it goes out on the net and checks 
all servers before ntpq -p is completed, take 5 or 6 seconds to do that, 
I'd have to say its working. dd-wrt hasn't an ntpq -p output, so I've 
left it to its own devices, listing its server as pool.ntp.org. It 
doesn't seem to have a switch to turn on .BCST.  That does seem odd as 
ISTR seeing it in an older version.

So I think I've done my part to reduce the load on the debian stratum 2 
servers pool. TANSTAAFL.

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#201677

On Fri, Oct 26, 2018 at 09:29:38AM -0400, Gene Heskett wrote:
> and it goes out on the net and checks 
> all servers before ntpq -p is completed, take 5 or 6 seconds to do that, 

That's DNS resolution.  It's looking up the IP addresses so it can
report names to you.  If you want to skip that, you can use "ntpq -p -n".
That one should be very fast.

[toc] | [prev] | [next] | [standalone]

#201683

On Friday 26 October 2018 09:53:39 Greg Wooledge wrote:

> On Fri, Oct 26, 2018 at 09:29:38AM -0400, Gene Heskett wrote:
> > and it goes out on the net and checks
> > all servers before ntpq -p is completed, take 5 or 6 seconds to do
> > that,
>
> That's DNS resolution.  It's looking up the IP addresses so it can
> report names to you.  If you want to skip that, you can use "ntpq -p
> -n". That one should be very fast.

And is instant, thanks Greg.

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#201673

On 2018-10-25, Gene Heskett <gheskett@shentel.net> wrote:

> Now this machine shows for ntpq -p:
>      remote           refid      st t when poll reach   delay   offset  jitter
>==============================================================================
> +159.203.158.197 45.33.103.94     3 u   59   64    3   19.551   -1.356  61.116
> *tick.mdacore.ne 130.207.244.240  2 u   61   64    3   30.488   -2.042   3.042
> -ntp3.junkemailf 216.218.254.202  2 u   59   64    3   82.196   -7.491   2.306
> +208.76.53.137   216.218.254.202  2 u   64   64    3   40.852   -2.476   0.889
>  192.168.71.255  .BCST.          16 u    -   64    0    0.000    0.000   0.000
>
> But should the .BCST. be a 16 ?? Or is that just the nature of the beast?
>>

>From what I can grok, yes, the .BCST line is normal because that is the
broadcast address for the sub-net to which you are broadcasting, and
ntpd cannot sync to itself (default stratum 16). 

I can't seem to find an example of a ntpq -p output that has a .BCST
address with a stratum other than 16 (maybe I'm not looking hard
enough) which leads me to believe it's okey-dokey.

Famous last words: I don't really know anything about this and so could be
partially, if not all, wet.


-- 
"Now she understood that Anna could not have been in lilac, and that her charm
was just that she always stood out against her attire, that her dress could
never be noticeable on her." Leo Tolstoy, Anna Karenina 

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web