On Saturday 14 March 2020 22:11:29 Andy Smith wrote:
> Hi,
>
> On Sat, Mar 14, 2020 at 09:49:43PM -0400, Gene Heskett wrote:
> > In an attempt to reduce the load on my time servers
>
> Is this an actual problem you have observed? I ask because there is
> very little that an individual can do to cause noticeable load on a
> time server. You would have to have many misconfigured machines
> requesting time every fraction of a second for anyone to notice
> above background noise.
>
> > A gene@shop:~$ sudo /etc/init.d/ntp status
> > [ ok ] NTP server is running.
> >
> > Which is typical when its all synched
>
> This isn't actually giving you any more information than the command
> you typed on your pi machine. All it's saying is that ntpd is
> running, which is the same as what is being reported on the pi.
>
> > but the pi is reporting:
> > pi@rpi4:/var/log/ntpstats $ sudo /etc//init.d/ntp status
> > ● ntp.service - Network Time Service
> > Loaded: loaded (/lib/systemd/system/ntp.service; enabled; vendor
> > preset: enabled)
> > Active: active (running) since Sat 2020-03-14 20:17:25 EDT; 57min
> > ago Docs: man:ntpd(8)
> > Process: 16957 ExecStart=/usr/lib/ntp/ntp-systemd-wrapper
> > (code=exited, status=0/SUCCESS)
> > Main PID: 16963 (ntpd)
>
> ntpd loaded and running then…
But is it fighting with a still active default? What do I remove to
defeat that if thats the case?
>
> > Mar 14 20:17:25 rpi4.coyote.den ntpd[16963]: kernel reports
> > TIME_ERROR: 0x2041: Clock Unsynchronized
> > Mar 14 20:17:25 rpi4.coyote.den ntpd[16963]: kernel reports
> > TIME_ERROR: 0x2041: Clock Unsynchronized
> >
> > What is wrong with my /etc/ntp.conf on the pi that is causing this
> > apparent failure?
>
> I assume you are referring to the "kernel reports TIME_ERROR" lines
> when you say "apparent failure". If so, this is only saying that the
> situation at the time the ntpd process started was that your clock
> was unsynchronized. It is not unexpected to see this.
But several hours later, not quite same report:
pi@rpi4:/var/log/ntpstats $ ntptime
ntp_gettime() returns code 5 (ERROR)
time e2183b1d.28d24e18 Sun, Mar 15 2020 1:26:53.159, (.159459185),
maximum error 16000000 us, estimated error 16000000 us, TAI offset 37
ntp_adjtime() returns code 5 (ERROR)
modes 0x0 (),
offset 0.000 us, frequency 0.000 ppm, interval 1 s,
maximum error 16000000 us, estimated error 16000000 us,
status 0x2041 (PLL,UNSYNC,NANO),
time constant 3, precision 0.001 us, tolerance 500 ppm,
And:pi@rpi4:/var/log/ntpstats $ ntpq -np
No association ID's returned
> What you would generally expect is for it to become synchronized in
> a fairly short period of time (minutes).
>
> While you have ntpd running on your pi, what is the output of:
>
> $ ntptime
pi@rpi4:/var/log/ntpstats $ ntptime
ntp_gettime() returns code 5 (ERROR)
time e2183162.541f7510 Sun, Mar 15 2020 0:45:22.328, (.328605133),
maximum error 16000000 us, estimated error 16000000 us, TAI offset 37
ntp_adjtime() returns code 5 (ERROR)
modes 0x0 (),
offset 0.000 us, frequency 0.000 ppm, interval 1 s,
maximum error 16000000 us, estimated error 16000000 us,
status 0x2041 (PLL,UNSYNC,NANO),
time constant 3, precision 0.001 us, tolerance 500 ppm,
> and
> $ ntpq -np
pi@rpi4:/var/log/ntpstats $ ntpq -np
No association ID's returned.
Thanks for any more help.>
> ?
The actual time on the pi is off maybe 3 seconds as it apparently sets it
somehow on a reboot, as at the instant I have a problem with a cnc
interface card which will reset/reboot it instantly on the first encoder
edge after starting linuxcnc which opens a link to the card over the spi
bus. Couple more good boards are in the mail. Last reboot from that
cause was late yesterday afternoon. So its drifted a few secs since.
> There may not be anything wrong with the time service on your pi. Or
> there might be, but it hasn't been demonstrated yet; the output of
> the above commands will tell us more.
>
> You might also like to compare those outputs to the outputs they
> provide on a machine you think is working.
>
One of the working machines, a wheezy install:
gene@GO704:~$ sudo ntptime
[sudo] password for gene:
ntp_gettime() returns code 0 (OK)
time e2183507.3a85339c Sun, Mar 15 2020 1:00:55.228, (.228595385),
maximum error 616076 us, estimated error 623 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
modes 0x0 (),
offset 486.479 us, frequency -33.106 ppm, interval 1 s,
maximum error 616076 us, estimated error 623 us,
status 0x6001 (PLL,NANO,MODE),
time constant 10, precision 0.001 us, tolerance 500 ppm,
gene@GO704:~$ sudo ntpq -np
remote refid st t when poll reach delay offset
jitter
==============================================================================
*192.168.71.3 5.103.128.88 2 u 953 1024 377 0.234 0.608
0.526
gene@GO704:~$
And a stretch machine:
gene@shop:~$ sudo ntpq -np
remote refid st t when poll reach delay offset
jitter
==============================================================================
*192.168.71.3 5.103.128.88 2 u 79 1024 377 0.250 -0.316
0.759
gene@shop:~$ sudo ntptime
ntp_gettime() returns code 0 (OK)
time e218372b.664c0dd0 Sun, Mar 15 2020 1:10:03.399, (.399598391),
maximum error 201783 us, estimated error 475 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
modes 0x0 (),
offset -308.131 us, frequency 2.938 ppm, interval 1 s,
maximum error 201783 us, estimated error 475 us,
status 0x2001 (PLL,NANO),
time constant 10, precision 0.001 us, tolerance 500 ppm,
> Additionally, this is not the cause of any problem, but I note you
> have only one "server" directive in your ntp.conf. Hopefully
> 192.168.71.3 itself has more than one "server" directive, because
> your other machines are trusting 192.168.71.3 to tell them the time
> (here I am assuming that "coyote.coyote.den" is also 192.168.71.3).
Yes, one and the same
> An odd number of servers, at least 3, are preferred so that if one
> of them goes bad, the NTP algorithms can detect that and ignore the
> source. With only one server there's no way to tell. With two, it
> can tell but not tell which one is correct. With three or more it
> can work it out.
>
> I don't think we've seen the ntp.conf for 192.168.71.3 so maybe it
> does have at least three "server" directives in there. If it
> doesn't, you should take care of that.
>
> If you have an always-on Internet connection I would also consider
> adding more "server" directives even to the clients. The local one
> (192.168.71.3) should still see most usage as long as it is a good
> timekeeper.
This is a fresh Asus 370 mobo, and it seems to be. What I wanted was to
sync to the debian servers with this machine, and then let it broadcast
to the rest of the local network, currently 3 amd64 boxes, and the rpi4.
I can add more stratum 2 stuff to this machine, and I can move this
machine to above the debian servers in the ntp.conf if order helps.
> Cheers,
> Andy
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)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
