Re: ntp problem in broadcastclients
On Friday 26 October 2018 09:01:50 Curt wrote:
> 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:
We ought to define a TLA for that, I propose FLW. :)
> I don't really know anything about this and so
> could be partially, if not all, wet.
Me too but I've got a dry towel. :-)
It does seem to be working, everything here is now on, and apparently
staying on, the same second, and I've reduced the load on the stratum 2
servers by 5 or 6 machines.
As I'm fond of saying TANSTAAFL. If we all, with multiple machine sites,
did this it would make a measureable difference in bandwidth used. But I
haven't a clue if windows can duplicate this. I don't allow its use
here.
--
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>
Reply to: