Re: ntp questions

[David Wright]

On Sun 15 Mar 2020 at 12:33:30 (+), G.W. Haywood wrote:
> On Sun, 15 Mar 2020, Gene Heskett wrote:
> 
> > ... 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,
> 
> Some observations about ntpd and NTP in general:
> 
> 1. Unless you're running a time laboratory, don't use ntpd.  Use chrony.
> In my experience it's much more forgiving, easier to configure and does
> the job it needs to do for those of us who are happy with accuracies in
> the order of a couple of milliseconds.  I used ntpd for decades.  Since
> I started using chrony a few years ago it has been *much* less trouble,
> and I no longer feel the need to be subscribed to a 'time' mailing list.
> This has the happy side-effect that I also don't need to worry about
> being berated by some NTP guru for using a Linux box as a time server.

For some reason, which I didn't discover, chrony wouldn't correct a
5-sec error for me, but that was many versions back. I must admit that
I didn't find anything to configure in either chrony or ntp, using
them just as they came out of the box. I still do.

https://lists.debian.org/debian-user/2017/06/msg00450.html

> 2. If you must use your own server, in addition to them use a pool of
> remote time servers such as provided by Debian.  You really don't want
> the time on your network hunting around following a single rogue box
> after it unexpectedly rebooted with the wrong time.  Please use the
> 'makestep' chrony directive on machines which aren't running 24/7; by
> all means use prefer, iburst etc. if you feel the need.

IIRC   makestep 1 3   was in chrony's default configuration.

Cheers,
David.

Re: ntp questions

[Gene Heskett]

On Sunday 15 March 2020 10:07:42 Tixy wrote:

> On Sun, 2020-03-15 at 08:37 -0500, John Hasler wrote:
> > BTW for controlling gadgets and machines I think that boards such as
> > the Pyboard, the Teensies (Sparkfun) and the Feathers (Adafruit) may
> > be much more suitable than the Pi.  These boards have control/DSP
> > oriented processors and lots of I/O instead of graphics and HDMI.
>
> Sounds sensible, however I believe Gene needs graphics as well for the
> CNC software's GUI; at least from what I've gathered over the years of
> him trying to get realtime kernels working on the Pi as well as
> propriety graphics. Personally, I've always though such a design
> architecture is totally bonkers, why isn't GUI and machine control
> completely separate things. But that's not Gene's fault, it's the
> software designers.

It can be split up, is a hassle but that needs 10GB ethernet, which I 
don't have.  Somewhere in the path to the shed and garage, in a sea of 
gigabit stuff, is a 100Mbit limit. Probably an older switch. And decent 
gigabit switches seem to have dried up in the local market. What I have 
works flawlessly, but still somewhat slow. And at 85, with a spare parts 
list beginniing to look like Lee Majors, I know I am approaching the end 
of my run here. But I'll also say its been one hell of a ride.  I've 
made that guy with the scythe blink first twice now. A very enjoyable 
feeling.

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 

Re: ntp questions

[Gene Heskett]

On Sunday 15 March 2020 09:55:56 deloptes wrote:

> Gene Heskett wrote:
> > Greetings all;
> >
> > In an attempt to reduce the load on my time servers and to mitigate
> > the jumps in system time that can play heck with timing errors of a
> > running LinuxCNc session, I have installed an ntp client on a
> > raspbian buster, and I think I have told it to listen to iburst from
> > this machine.  All my other machine are setup similar and appear to
> > be working ok.
> >
> > But the pi with an identical config is still not synching.
> > 2 working machine symply say ok when asked for status, old wheezy
> > installs.
> > A gene@shop:~$ sudo /etc/init.d/ntp status
> > [ ok ] NTP server is running.
> >
> > Which is typical when its all synched
> >
> > 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)
> > Tasks: 2 (limit: 4033)
> > Memory: 936.0K
> > CGroup: /system.slice/ntp.service
> > └─16963 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 114:122
> >
> > Mar 14 20:17:25 rpi4.coyote.den ntpd[16963]: leapsecond file
> > ('/usr/share/zoneinfo/leap-seconds.list'): loaded,
> > expire=2020-06-28T00:00:00Z last=2017-01-01T00:00:00Z ofs=37
> > Mar 14 20:17:25 rpi4.coyote.den ntpd[16963]: Listen and drop on 0
> > v6wildcard [::]:123
> > Mar 14 20:17:25 rpi4.coyote.den ntpd[16963]: Listen and drop on 1
> > v4wildcard 0.0.0.0:123
> > Mar 14 20:17:25 rpi4.coyote.den ntpd[16963]: Listen normally on 2 lo
> > 127.0.0.1:123
> > Mar 14 20:17:25 rpi4.coyote.den ntpd[16963]: Listen normally on 3
> > eth0 192.168.71.13:123
> > Mar 14 20:17:25 rpi4.coyote.den ntpd[16963]: Listen normally on 4 lo
> > [::1]:123
> > Mar 14 20:17:25 rpi4.coyote.den ntpd[16963]: Listening on routing
> > socket on fd #21 for interface updates
> > Mar 14 20:17:25 rpi4.coyote.den ntpd[16963]: Listen for broadcasts
> > to 192.168.71.255 on interface #3 eth0
> > 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?
> >
> > Looking for ntp.conf diffs a grep -v '#' reports for a working
> > machines ntp.conf:
> > driftfile /var/lib/ntp/ntp.drift
> > statsdir /var/log/ntpstats/
> > statistics loopstats peerstats clockstats
> > filegen loopstats file loopstats type day enable
> > filegen peerstats file peerstats type day enable
> > filegen clockstats file clockstats type day enable
> > server 192.168.71.3 iburst
> > restrict -4 default kod notrap nomodify nopeer noquery
> > restrict -6 default kod notrap nomodify nopeer noquery
> > restrict 127.0.0.1
> > restrict ::1
> > disable auth
> > broadcastclient
> >
> > while that same inverted grep on the pi reports:
> >
> > driftfile /var/lib/ntp/ntp.drift
> > leapfile /usr/share/zoneinfo/leap-seconds.list
> > statsdir /var/log/ntpstats/
> > statistics loopstats peerstats clockstats
> > filegen loopstats file loopstats type day enable
> > filegen peerstats file peerstats type day enable
> > filegen clockstats file clockstats type day enable
> > server coyote.coyote.den iburst
> > restrict -4 default kod notrap nomodify nopeer noquery limited
> > restrict -6 default kod notrap nomodify nopeer noquery limited
> > restrict 127.0.0.1
> > restrict ::1
> > restrict source notrap nomodify noquery <-different, # it no change
> > broadcast 192.168.71.255
> > disable auth
> > broadcastclient
> >
> > Thanks everybody.
> >
> >
> > Cheers, Gene Heskett
>
> I spent 1-2 days last year configuring a set of ntp servers and client
> and had also difficulties getting all done.
>
> unfortunately I can not access the notes I did, but I'll post to you
> tomorrow
>
Don't worry about it, it finally synched up and its all running on debian 
time now.  Now all I need is some fresh mesa 7i90HD cards and I'll be 
back in the race.

Thanks delooptes.

> regards


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 

Re: ntp questions

[Gene Heskett]

On Sunday 15 March 2020 08:33:30 G.W. Haywood wrote:

> Hi there,
>
> On Sun, 15 Mar 2020, Gene Heskett wrote:
> > ... 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,
>
> Some observations about ntpd and NTP in general:
>
> 1. Unless you're running a time laboratory, don't use ntpd.  Use
> chrony. In my experience it's much more forgiving, easier to configure
> and does the job it needs to do for those of us who are happy with
> accuracies in the order of a couple of milliseconds.  I used ntpd for
> decades.  Since I started using chrony a few years ago it has been
> *much* less trouble, and I no longer feel the need to be subscribed to
> a 'time' mailing list. This has the happy side-effect that I also
> don't need to worry about being berated by some NTP guru for using a
> Linux box as a time server.
>
> 2. If you must use your own server, in addition to them use a pool of
> remote time servers such as provided by Debian.  You really don't want
> the time on your network hunting around following a single rogue box
> after it unexpectedly rebooted with the wrong time.  Please use the
> 'makestep' chrony directive on machines which aren't running 24/7; by
> all means use prefer, iburst etc. if you feel the need.
>
> 3. Enable the (three) chrony logs and look at them often - especially
> just after boot, so you get a feel for how quickly you can expect the
> time to be recovered.  It should be no more than a couple of minutes.
>
> 4. Use e.g. Nagios/Icinga to monitor things like this.  I can let you
> have some example graphs privately, and configuration snippets too if
> it will help.  If the time on any box goes out of spec. I get an email
> within minutes.
>
> > 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.
>
> 5. You shouldn't worry about strata yourself, let the servers do that.
> Low strata don't necessarily equate to high accuracy, and vice-versa.
>
> 6. For a few $currency_units you can add a RTC module to any device
> which doesn't have one.  I prefer to keep the hardware clock on UTC,
> and let the OS and/or application software worry about any timezones,
> and especially about changes such as Daylight Saving.  With a bit of
> effort, the hardware clock will see only the (very) occasional leap
> second adjustments.
>
> 7. See https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse for
> many ways of inadvertently abusing NTP, which you should avoid, and a
> few ways of being led down the garden path too (also to be avoided).
>
> > currently 3 amd64 boxes, and the rpi4.
>
> I note with interest that you're using a Raspberry Pi 4.  In my recent
> experience these are particularly flaky compared with other Pis - and,
> well, everything else.  They really hate disturbances on the USB ports
> for example and will hang/crash/reboot/remount-read-only/trash-the-fs
> without warning if you should happen to plug in a second USB camera or
> disc.  It seems to me it's the power conditioning that's at the root
> of this, but at the moment I haven't worked with them for long enough
> to say much more than that.  I'm using Pi 3s for things like my backup
> servers, they seem to be much more reliable.  I'm writing this mail on
> a Pi3b+ which has been my desktop thin client and also a backup server
> for some months.  It's never put a foot wrong.  Even the one venerable
> Pi 2 that we have here is more reliable than the 4.  The Zeros seem OK
> if you don't overtax them, but we tend to use them just for gadgetry.
> Or rather _did_ use them.  AFAICT at the moment you can't actually buy
> one anywhere, and this situation does not seem to be improving; so any
> time spent designing with Zeros seems to have been pretty much wasted.

This instant reboot thing is the first time I have had anything happen to 
any pi in the 3 or higher category. With a ups, until now, rebooting has 
absolutely been at my pleasure. I can't say the same for my 3 wintel 
boxes running other machines. I went to a pi4 for this because the pi3 
was doing a pretty good jub but dragging its tongue on the floor, 
whereas the pi4, at a fixed 800MHz, is effectively parked in a beach 
chair under an umbrella, feet up and Martini in hand, up till now.

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 

Re: ntp questions

[Gene Heskett]

On Sunday 15 March 2020 07:38:19 John Hasler wrote:

> Install Chrony.

No need to a/o as an hour or so ago ntp finally achieved a lock.

oot@rpi4:~# /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 Sun 2020-03-15 07:52:23 EDT; 3h 23min ago
 Docs: man:ntpd(8)
  Process: 4066 ExecStart=/usr/lib/ntp/ntp-systemd-wrapper (code=exited, 
status=0/SUCCESS)
 Main PID: 4072 (ntpd)
Tasks: 2 (limit: 4033)
   Memory: 1.1M
   CGroup: /system.slice/ntp.service
   └─4072 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 114:122

Mar 15 08:02:42 rpi4.coyote.den ntpd[4072]: 216.117.164.1 local addr 
192.168.71.13 -> 
Mar 15 08:09:15 rpi4.coyote.den ntpd[4072]: 91.207.136.50 local addr 
192.168.71.13 -> 
Mar 15 08:09:22 rpi4.coyote.den ntpd[4072]: 5.20.0.20 local addr 192.168.71.13 
-> 
Mar 15 08:09:30 rpi4.coyote.den ntpd[4072]: 195.78.244.50 local addr 
192.168.71.13 -> 
Mar 15 08:11:38 rpi4.coyote.den ntpd[4072]: 23.31.21.164 local addr 
192.168.71.13 -> 
Mar 15 08:17:12 rpi4.coyote.den ntpd[4072]: 138.68.201.49 local addr 
192.168.71.13 -> 
Mar 15 08:17:13 rpi4.coyote.den ntpd[4072]: 144.172.126.201 local addr 
192.168.71.13 -> 
Mar 15 08:17:15 rpi4.coyote.den ntpd[4072]: 216.229.4.66 local addr 
192.168.71.13 -> 
Mar 15 08:17:16 rpi4.coyote.den ntpd[4072]: 94.130.184.193 local addr 
192.168.71.13 -> 
Mar 15 08:18:23 rpi4.coyote.den ntpd[4072]: 37.59.58.17 local addr 
192.168.71.13 -> 

And I note that my broadcast from this machine is not shown above.

I do not know how chrony works to correct the time, but by late this 
morning ntp has indeed achieved a lock. ntp locks by gently slewing the 
clock rate if its within a minutes wide window. The existing raspbian 
method may jump it, and this confuses LinuxCNC, makeing it think the 
machine is way out of position when its checking every milisecond, and 
the default method may jump the time by several milliseconds, causing 
LinuxCNC to throw a false following error.  

Nevertheless its a showstopper, freezing it place as quick as it can 
given the decel limits at that instant, until a much slower human clears
the error and probably restarts what could be a several hour proceedure 
from the top. Because changing a tool provides a handy breakpoint, and 
is a by hand operation here, I generally write a job in breaks at tool 
changes.

This did take longer than I thought it would take as the crash doesn't 
give the fake hwclock time to store its latest time, so on the reboot 
it make be several seconds out of synch.  Now that I know its working, 
I'll quit worrying about it.

The correct fix is of course to fix the crashing, but that fix is in the 
mail yet. That faint knocking sound is me, knocking on wood that a new 
$59 card fixes it. And I still have work to do rebuilding the the encoder.

That is going to need the 3rd ATS667 jbwelded to a brass base. and that
base then fitted to a curved alu bracket with a couple 0-80 screws in 
slots to allow its mechanical timing to be adjusted for a good quadrature.
This is what tells LinuxCNC where in the spindles rotation it is, in this 
case every 1.5 degrees, so it knows where to put the cutting tool when 
its carving threads. A secondary problem is that due to factory miss-
adjustment which added several tons of engagement pressure 80 years ago, 
the wear on the gear I am senseing is uneven which has resulted in teeth 
that vary in magnetic width. And that eats up some timing tolerance, 
hence the need for some adjustabiity.  A new modern gear would be nice.
But is made out of very pure unobtainium in 2020. So we run what we brung.
:-)

Cheers & and thanks to you all, 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 

Re: ntp questions

[John Hasler]

Tixy writes:
> Sounds sensible, however I believe Gene needs graphics as well for the
> CNC software's GUI; at least from what I've gathered over the years of
> him trying to get realtime kernels working on the Pi as well as
> propriety graphics. Personally, I've always though such a design
> architecture is totally bonkers, why isn't GUI and machine control
> completely separate things. But that's not Gene's fault, it's the
> software designers.

The software was designed before cheap single-board computers became
available: the idea was to repurpose a desktop pc to do everything.

My lathe and my mill don't need to have their clocks synchronized,
though, as long all the servos on the mill agree with the central
controller[1].  Only the latter needs a display, and it need not know
what time it really is.

[1] Hypothetically: both are manual at present.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: ntp questions

[Tixy]

On Sun, 2020-03-15 at 08:37 -0500, John Hasler wrote:
> BTW for controlling gadgets and machines I think that boards such as the
> Pyboard, the Teensies (Sparkfun) and the Feathers (Adafruit) may be much
> more suitable than the Pi.  These boards have control/DSP oriented
> processors and lots of I/O instead of graphics and HDMI.

Sounds sensible, however I believe Gene needs graphics as well for the
CNC software's GUI; at least from what I've gathered over the years of
him trying to get realtime kernels working on the Pi as well as
propriety graphics. Personally, I've always though such a design
architecture is totally bonkers, why isn't GUI and machine control
completely separate things. But that's not Gene's fault, it's the
software designers.

-- 
Tixy

Re: ntp questions

[deloptes]

Gene Heskett wrote:

> Greetings all;
> 
> In an attempt to reduce the load on my time servers and to mitigate the
> jumps in system time that can play heck with timing errors of a running
> LinuxCNc session, I have installed an ntp client on a raspbian buster,
> and I think I have told it to listen to iburst from this machine.  All
> my other machine are setup similar and appear to be working ok.
> 
> But the pi with an identical config is still not synching.
> 2 working machine symply say ok when asked for status, old wheezy
> installs.
> A gene@shop:~$ sudo /etc/init.d/ntp status
> [ ok ] NTP server is running.
> 
> Which is typical when its all synched
> 
> 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)
> Tasks: 2 (limit: 4033)
> Memory: 936.0K
> CGroup: /system.slice/ntp.service
> └─16963 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 114:122
> 
> Mar 14 20:17:25 rpi4.coyote.den ntpd[16963]: leapsecond file
> ('/usr/share/zoneinfo/leap-seconds.list'): loaded,
> expire=2020-06-28T00:00:00Z last=2017-01-01T00:00:00Z ofs=37
> Mar 14 20:17:25 rpi4.coyote.den ntpd[16963]: Listen and drop on 0
> v6wildcard [::]:123
> Mar 14 20:17:25 rpi4.coyote.den ntpd[16963]: Listen and drop on 1
> v4wildcard 0.0.0.0:123
> Mar 14 20:17:25 rpi4.coyote.den ntpd[16963]: Listen normally on 2 lo
> 127.0.0.1:123
> Mar 14 20:17:25 rpi4.coyote.den ntpd[16963]: Listen normally on 3 eth0
> 192.168.71.13:123
> Mar 14 20:17:25 rpi4.coyote.den ntpd[16963]: Listen normally on 4 lo
> [::1]:123
> Mar 14 20:17:25 rpi4.coyote.den ntpd[16963]: Listening on routing socket
> on fd #21 for interface updates
> Mar 14 20:17:25 rpi4.coyote.den ntpd[16963]: Listen for broadcasts to
> 192.168.71.255 on interface #3 eth0
> 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?
> 
> Looking for ntp.conf diffs a grep -v '#' reports for a working machines
> ntp.conf:
> driftfile /var/lib/ntp/ntp.drift
> statsdir /var/log/ntpstats/
> statistics loopstats peerstats clockstats
> filegen loopstats file loopstats type day enable
> filegen peerstats file peerstats type day enable
> filegen clockstats file clockstats type day enable
> server 192.168.71.3 iburst
> restrict -4 default kod notrap nomodify nopeer noquery
> restrict -6 default kod notrap nomodify nopeer noquery
> restrict 127.0.0.1
> restrict ::1
> disable auth
> broadcastclient
> 
> while that same inverted grep on the pi reports:
> 
> driftfile /var/lib/ntp/ntp.drift
> leapfile /usr/share/zoneinfo/leap-seconds.list
> statsdir /var/log/ntpstats/
> statistics loopstats peerstats clockstats
> filegen loopstats file loopstats type day enable
> filegen peerstats file peerstats type day enable
> filegen clockstats file clockstats type day enable
> server coyote.coyote.den iburst
> restrict -4 default kod notrap nomodify nopeer noquery limited
> restrict -6 default kod notrap nomodify nopeer noquery limited
> restrict 127.0.0.1
> restrict ::1
> restrict source notrap nomodify noquery <-different, # it no change
> broadcast 192.168.71.255
> disable auth
> broadcastclient
> 
> Thanks everybody.
> 
> 
> Cheers, Gene Heskett

I spent 1-2 days last year configuring a set of ntp servers and client and
had also difficulties getting all done.

unfortunately I can not access the notes I did, but I'll post to you
tomorrow

regards

Re: ntp questions

[John Hasler]

G.W. Haywood writes:
> 1. Unless you're running a time laboratory, don't use ntpd.  Use
> chrony.  In my experience it's much more forgiving, easier to
> configure and does the job it needs to do for those of us who are
> happy with accuracies in the order of a couple of milliseconds.

Actually Chrony is as accurate as NTPd and perhaps more accurate.

If I understand correctly Gene needs to synchronize a group of machine
control computers.  They don't care what time it really is as long as
they all agree.  I don't think that he would mind being a time island.

BTW for controlling gadgets and machines I think that boards such as the
Pyboard, the Teensies (Sparkfun) and the Feathers (Adafruit) may be much
more suitable than the Pi.  These boards have control/DSP oriented
processors and lots of I/O instead of graphics and HDMI.  They also run
MicroPython.  I haven't used it yet but I'm about to.  Looks very
interesting.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: ntp questions

[G.W. Haywood]

Hi there,

On Sun, 15 Mar 2020, Gene Heskett wrote:


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


Some observations about ntpd and NTP in general:

1. Unless you're running a time laboratory, don't use ntpd.  Use chrony.
In my experience it's much more forgiving, easier to configure and does
the job it needs to do for those of us who are happy with accuracies in
the order of a couple of milliseconds.  I used ntpd for decades.  Since
I started using chrony a few years ago it has been *much* less trouble,
and I no longer feel the need to be subscribed to a 'time' mailing list.
This has the happy side-effect that I also don't need to worry about
being berated by some NTP guru for using a Linux box as a time server.

2. If you must use your own server, in addition to them use a pool of
remote time servers such as provided by Debian.  You really don't want
the time on your network hunting around following a single rogue box
after it unexpectedly rebooted with the wrong time.  Please use the
'makestep' chrony directive on machines which aren't running 24/7; by
all means use prefer, iburst etc. if you feel the need.

3. Enable the (three) chrony logs and look at them often - especially
just after boot, so you get a feel for how quickly you can expect the
time to be recovered.  It should be no more than a couple of minutes.

4. Use e.g. Nagios/Icinga to monitor things like this.  I can let you
have some example graphs privately, and configuration snippets too if
it will help.  If the time on any box goes out of spec. I get an email
within minutes.


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.


5. You shouldn't worry about strata yourself, let the servers do that.
Low strata don't necessarily equate to high accuracy, and vice-versa.

6. For a few $currency_units you can add a RTC module to any device
which doesn't have one.  I prefer to keep the hardware clock on UTC,
and let the OS and/or application software worry about any timezones,
and especially about changes such as Daylight Saving.  With a bit of
effort, the hardware clock will see only the (very) occasional leap
second adjustments.

7. See https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse for
many ways of inadvertently abusing NTP, which you should avoid, and a
few ways of being led down the garden path too (also to be avoided).


currently 3 amd64 boxes, and the rpi4.


I note with interest that you're using a Raspberry Pi 4.  In my recent
experience these are particularly flaky compared with other Pis - and,
well, everything else.  They really hate disturbances on the USB ports
for example and will hang/crash/reboot/remount-read-only/trash-the-fs
without warning if you should happen to plug in a second USB camera or
disc.  It seems to me it's the power conditioning that's at the root
of this, but at the moment I haven't worked with them for long enough
to say much more than that.  I'm using Pi 3s for things like my backup
servers, they seem to be much more reliable.  I'm writing this mail on
a Pi3b+ which has been my desktop thin client and also a backup server
for some months.  It's never put a foot wrong.  Even the one venerable
Pi 2 that we have here is more reliable than the 4.  The Zeros seem OK
if you don't overtax them, but we tend to use them just for gadgetry.
Or rather _did_ use them.  AFAICT at the moment you can't actually buy
one anywhere, and this situation does not seem to be improving; so any
time spent designing with Zeros seems to have been pretty much wasted.

--

73,
Ged.

Re: ntp questions

[John Hasler]

Install Chrony.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: ntp questions

[Andrei POPESCU]

On Sb, 14 mar 20, 23:03:45, David Wright wrote:
> 
> Is this something to do with the Pi not having a hardware clock?
> IOW when it boots up, it doesn't have a clue what time it is.
> 
> I've read that you should run   ntpd -g -q   on the Pi, having
> first stopped its daemon/service (according to how you're
> running it, sysvinit/systemd). This allows a time jump from
> 4004 BC or whatever it boots up at. Then restart the
> daemon/service.

fake-hwclock could be used to jump the clock within a reasonable range 
(e.g. time of last shut down) on boot.

Not needed if you already run systemd.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: ntp questions

[Andrei POPESCU]

On Sb, 14 mar 20, 21:39:36, David Christensen wrote:
> 
> Have you tried installing ntpdate on the problem machine and rebooting?

As per its package description 'ntpdate' is deprecated.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: ntp questions

[David Christensen]

On 2020-03-14 22:57, Gene Heskett wrote:

On Sunday 15 March 2020 00:39:36 David Christensen wrote:


On 2020-03-14 18:49, Gene Heskett wrote:



I have installed an ntp client on a raspbian buster,



not synching.



Have you tried installing ntpdate on the problem machine and
rebooting?



reboot did take long: no joy
pi@rpi4:~ $ ntpq -np
  remote   refid  st t when poll reach   delay   offset  jitter
==
  0.debian.pool.n .POOL.  16 p-   6400.0000.000   0.002
  1.debian.pool.n .POOL.  16 p-   6400.0000.000   0.002
  2.debian.pool.n .POOL.  16 p-   6400.0000.000   0.002
  3.debian.pool.n .POOL.  16 p-   6400.0000.000   0.002
pi@rpi4:~ $ ntpdate
15 Mar 01:55:06 ntpdate[1371]: no servers can be used, exiting



This is my laptop.  I believe the clock is correct:

2020-03-14 23:22:09 root@tinkywinky ~
# cat /etc/debian_version ; uname -a
9.12
Linux tinkywinky 4.9.0-12-amd64 #1 SMP Debian 4.9.210-1 (2020-01-20) 
x86_64 GNU/Linux



2020-03-14 23:22:52 root@tinkywinky ~
# find /etc -name '*ntp*'
/etc/ntp.conf
/etc/dhcp/dhclient-exit-hooks.d/ntp
/etc/rc5.d/S01ntp
/etc/init.d/ntp
/etc/apparmor.d/tunables/ntpd
/etc/apparmor.d/local/usr.sbin.ntpd
/etc/apparmor.d/usr.sbin.ntpd
/etc/cron.daily/ntp
/etc/rc3.d/S01ntp
/etc/rc4.d/S01ntp
/etc/apparmor/init/network-interface-security/usr.sbin.ntpd
/etc/NetworkManager/dispatcher.d/ntp
/etc/default/ntp
/etc/rc2.d/S01ntp


2020-03-14 23:23:48 root@tinkywinky ~
# dpkg-query --list ntp
Desired=Unknown/Install/Remove/Purge/Hold
| 
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend

|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  ntp1:4.2.8p10+d amd64Network Time Protocol 
daemon and



2020-03-14 23:23:57 root@tinkywinky ~
# dpkg-query --show ntp
ntp 1:4.2.8p10+dfsg-3+deb9u2


2020-03-14 23:24:25 root@tinkywinky ~
# grep -v '#' /etc/ntp.conf  | grep .
driftfile /var/lib/ntp/ntp.drift
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
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
restrict -4 default kod notrap nomodify nopeer noquery limited
restrict -6 default kod notrap nomodify nopeer noquery limited
restrict 127.0.0.1
restrict ::1
restrict source notrap nomodify noquery


2020-03-14 23:24:43 root@tinkywinky ~
# ntpq -np
 remote   refid  st t when poll reach   delay   offset 
jitter

==
 0.debian.pool.n .POOL.  16 p-   6400.0000.000 
 0.002
 1.debian.pool.n .POOL.  16 p-   6400.0000.000 
 0.002
 2.debian.pool.n .POOL.  16 p-   6400.0000.000 
 0.002
 3.debian.pool.n .POOL.  16 p-   6400.0000.000 
 0.002
+158.69.248.26   214.176.184.39   2 u  106  128  377   85.7873.088 
0.834
+162.159.200.123 10.4.0.197   3 u   78  128  377   25.3571.664 
1.033
-185.254.101.25  193.52.136.2 3 u   13  256  377  158.7333.369 
1.204
*47.190.36.235   139.78.97.1282 u   30  128  377   58.4661.621 
1.008
-185.121.25.242  85.199.214.982 u   68  256  377  161.6153.148 
1.120
-213.172.105.106 213.172.96.142 u  136  256  377  182.5003.087 
0.759



It looks like both of our machines are unable to connect to the 
*.debian.pool.ntp.org servers, but my machine has somehow found six 
servers than it can connect to.  I don't know how or why -- my NTP 
knowledge is limited to a general awareness of the network service, and 
installing and removing packages.



My next steps would be:

# apt-get purge ntp ntpdate


reboot, and:

# apt-get install ntp ntpdate


David

Re: ntp questions

[Gene Heskett]

On Sunday 15 March 2020 00:39:36 David Christensen wrote:

> On 2020-03-14 18:49, Gene Heskett wrote:
> > Greetings all;
> >
> > In an attempt to reduce the load on my time servers and to mitigate
> > the jumps in system time that can play heck with timing errors of a
> > running LinuxCNc session, I have installed an ntp client on a
> > raspbian buster, and I think I have told it to listen to iburst from
> > this machine.  All my other machine are setup similar and appear to
> > be working ok.
> >
> > But the pi with an identical config is still not synching.
> > 2 working machine symply say ok when asked for status, old wheezy
> > installs.
> > A gene@shop:~$ sudo /etc/init.d/ntp status
> > [ ok ] NTP server is running.
> >
> > Which is typical when its all synched
> >
> > 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)
> >  Tasks: 2 (limit: 4033)
> > Memory: 936.0K
> > CGroup: /system.slice/ntp.service
> > └─16963 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u
> > 114:122
> >
> > Mar 14 20:17:25 rpi4.coyote.den ntpd[16963]: leapsecond file
> > ('/usr/share/zoneinfo/leap-seconds.list'): loaded,
> > expire=2020-06-28T00:00:00Z last=2017-01-01T00:00:00Z ofs=37
> > Mar 14 20:17:25 rpi4.coyote.den ntpd[16963]: Listen and drop on 0
> > v6wildcard [::]:123
> > Mar 14 20:17:25 rpi4.coyote.den ntpd[16963]: Listen and drop on 1
> > v4wildcard 0.0.0.0:123
> > Mar 14 20:17:25 rpi4.coyote.den ntpd[16963]: Listen normally on 2 lo
> > 127.0.0.1:123
> > Mar 14 20:17:25 rpi4.coyote.den ntpd[16963]: Listen normally on 3
> > eth0 192.168.71.13:123
> > Mar 14 20:17:25 rpi4.coyote.den ntpd[16963]: Listen normally on 4 lo
> > [::1]:123
> > Mar 14 20:17:25 rpi4.coyote.den ntpd[16963]: Listening on routing
> > socket on fd #21 for interface updates
> > Mar 14 20:17:25 rpi4.coyote.den ntpd[16963]: Listen for broadcasts
> > to 192.168.71.255 on interface #3 eth0
> > 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?
> >
> > Looking for ntp.conf diffs a grep -v '#' reports for a working
> > machines ntp.conf:
> > driftfile /var/lib/ntp/ntp.drift
> > statsdir /var/log/ntpstats/
> > statistics loopstats peerstats clockstats
> > filegen loopstats file loopstats type day enable
> > filegen peerstats file peerstats type day enable
> > filegen clockstats file clockstats type day enable
> > server 192.168.71.3 iburst
> > restrict -4 default kod notrap nomodify nopeer noquery
> > restrict -6 default kod notrap nomodify nopeer noquery
> > restrict 127.0.0.1
> > restrict ::1
> > disable auth
> > broadcastclient
> >
> > while that same inverted grep on the pi reports:
> >
> > driftfile /var/lib/ntp/ntp.drift
> > leapfile /usr/share/zoneinfo/leap-seconds.list
> > statsdir /var/log/ntpstats/
> > statistics loopstats peerstats clockstats
> > filegen loopstats file loopstats type day enable
> > filegen peerstats file peerstats type day enable
> > filegen clockstats file clockstats type day enable
> > server coyote.coyote.den iburst
> > restrict -4 default kod notrap nomodify nopeer noquery limited
> > restrict -6 default kod notrap nomodify nopeer noquery limited
> > restrict 127.0.0.1
> > restrict ::1
> > restrict source notrap nomodify noquery <-different, # it no change
> > broadcast 192.168.71.255
> > disable auth
> > broadcastclient
> >
> > Thanks everybody.
> >
> >
> > Cheers, Gene Heskett
>
> Have you tried installing ntpdate on the problem machine and
> rebooting?
>
>
> David
reboot did take long: no joy
pi@rpi4:~ $ ntpq -np
 remote   refid  st t when poll reach   delay   offset  jitter
==
 0.debian.pool.n .POOL.  16 p-   6400.0000.000   0.002
 1.debian.pool.n .POOL.  16 p-   6400.0000.000   0.002
 2.debian.pool.n .POOL.  16 p-   6400.0000.000   0.002
 3.debian.pool.n .POOL.  16 p-   6400.0000.000   0.002
pi@rpi4:~ $ ntpdate
15 Mar 01:55:06 ntpdate[1371]: no servers can be used, exiting


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 

Re: ntp questions

[Gene Heskett]

On Sunday 15 March 2020 00:39:36 David Christensen wrote:

> On 2020-03-14 18:49, Gene Heskett wrote:
> > Greetings all;
> >
> > In an attempt to reduce the load on my time servers and to mitigate
> > the jumps in system time that can play heck with timing errors of a
> > running LinuxCNc session, I have installed an ntp client on a
> > raspbian buster, and I think I have told it to listen to iburst from
> > this machine.  All my other machine are setup similar and appear to
> > be working ok.
> >
> > But the pi with an identical config is still not synching.
> > 2 working machine symply say ok when asked for status, old wheezy
> > installs.
> > A gene@shop:~$ sudo /etc/init.d/ntp status
> > [ ok ] NTP server is running.
> >
> > Which is typical when its all synched
> >
> > 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)
> >  Tasks: 2 (limit: 4033)
> > Memory: 936.0K
> > CGroup: /system.slice/ntp.service
> > └─16963 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u
> > 114:122
> >
> > Mar 14 20:17:25 rpi4.coyote.den ntpd[16963]: leapsecond file
> > ('/usr/share/zoneinfo/leap-seconds.list'): loaded,
> > expire=2020-06-28T00:00:00Z last=2017-01-01T00:00:00Z ofs=37
> > Mar 14 20:17:25 rpi4.coyote.den ntpd[16963]: Listen and drop on 0
> > v6wildcard [::]:123
> > Mar 14 20:17:25 rpi4.coyote.den ntpd[16963]: Listen and drop on 1
> > v4wildcard 0.0.0.0:123
> > Mar 14 20:17:25 rpi4.coyote.den ntpd[16963]: Listen normally on 2 lo
> > 127.0.0.1:123
> > Mar 14 20:17:25 rpi4.coyote.den ntpd[16963]: Listen normally on 3
> > eth0 192.168.71.13:123
> > Mar 14 20:17:25 rpi4.coyote.den ntpd[16963]: Listen normally on 4 lo
> > [::1]:123
> > Mar 14 20:17:25 rpi4.coyote.den ntpd[16963]: Listening on routing
> > socket on fd #21 for interface updates
> > Mar 14 20:17:25 rpi4.coyote.den ntpd[16963]: Listen for broadcasts
> > to 192.168.71.255 on interface #3 eth0
> > 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?
> >
> > Looking for ntp.conf diffs a grep -v '#' reports for a working
> > machines ntp.conf:
> > driftfile /var/lib/ntp/ntp.drift
> > statsdir /var/log/ntpstats/
> > statistics loopstats peerstats clockstats
> > filegen loopstats file loopstats type day enable
> > filegen peerstats file peerstats type day enable
> > filegen clockstats file clockstats type day enable
> > server 192.168.71.3 iburst
> > restrict -4 default kod notrap nomodify nopeer noquery
> > restrict -6 default kod notrap nomodify nopeer noquery
> > restrict 127.0.0.1
> > restrict ::1
> > disable auth
> > broadcastclient
> >
> > while that same inverted grep on the pi reports:
> >
> > driftfile /var/lib/ntp/ntp.drift
> > leapfile /usr/share/zoneinfo/leap-seconds.list
> > statsdir /var/log/ntpstats/
> > statistics loopstats peerstats clockstats
> > filegen loopstats file loopstats type day enable
> > filegen peerstats file peerstats type day enable
> > filegen clockstats file clockstats type day enable
> > server coyote.coyote.den iburst
> > restrict -4 default kod notrap nomodify nopeer noquery limited
> > restrict -6 default kod notrap nomodify nopeer noquery limited
> > restrict 127.0.0.1
> > restrict ::1
> > restrict source notrap nomodify noquery <-different, # it no change
> > broadcast 192.168.71.255
> > disable auth
> > broadcastclient
> >
> > Thanks everybody.
> >
> >
> > Cheers, Gene Heskett
>
> Have you tried installing ntpdate on the problem machine and
> rebooting?
>
>
> David
Done, and its near 2am locally, I'll continue this when I come to in the 
daytime.  Thanks.

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 

Re: ntp questions

[Gene Heskett]

On Sunday 15 March 2020 00:03:45 David Wright wrote:

> ntpd -g -q

That gets me this and I don't think it will return:
pi@rpi4:/var/log/ntpstats $ sudo ntpd -g -q
15 Mar 01:31:43 ntpd[19606]: ntpd 4.2.8p12@1.3728-o (1): Starting
15 Mar 01:31:43 ntpd[19606]: Command line: ntpd -g -q
15 Mar 01:31:43 ntpd[19606]: proto: precision = 1.371 usec (-19)
15 Mar 01:31:43 ntpd[19606]: leapsecond file 
('/usr/share/zoneinfo/leap-seconds.list'): good hash signature
15 Mar 01:31:43 ntpd[19606]: leapsecond file 
('/usr/share/zoneinfo/leap-seconds.list'): loaded, 
expire=2020-06-28T00:00:00Z last=2017-01-01T00:00:00Z ofs=37
15 Mar 01:31:43 ntpd[19606]: Listen and drop on 0 v6wildcard [::]:123
15 Mar 01:31:43 ntpd[19606]: Listen and drop on 1 v4wildcard 0.0.0.0:123
15 Mar 01:31:43 ntpd[19606]: Listen normally on 2 lo 127.0.0.1:123
15 Mar 01:31:43 ntpd[19606]: Listen normally on 3 eth0 192.168.71.13:123
15 Mar 01:31:43 ntpd[19606]: Listen normally on 4 lo [::1]:123
15 Mar 01:31:43 ntpd[19606]: Listening on routing socket on fd #21 for 
interface updates
15 Mar 01:31:43 ntpd[19606]: Listen for broadcasts to 192.168.71.255 on 
interface #3 eth0

Adding a -b gets this, so the pi isn't getting any time from anyplace: 

pi@rpi4:/var/log/ntpstats $ sudo ntpd -g -b -q
15 Mar 01:44:11 ntpd[19703]: ntpd 4.2.8p12@1.3728-o (1): Starting
15 Mar 01:44:11 ntpd[19703]: Command line: ntpd -g -b -q
15 Mar 01:44:11 ntpd[19703]: proto: precision = 1.482 usec (-19)
15 Mar 01:44:11 ntpd[19703]: Unable to listen for broadcasts, no 
broadcast interfaces available
15 Mar 01:44:11 ntpd[19703]: leapsecond file 
('/usr/share/zoneinfo/leap-seconds.list'): good hash signature
15 Mar 01:44:11 ntpd[19703]: leapsecond file 
('/usr/share/zoneinfo/leap-seconds.list'): loaded, 
expire=2020-06-28T00:00:00Z last=2017-01-01T00:00:00Z ofs=37
15 Mar 01:44:11 ntpd[19703]: Listen and drop on 0 v6wildcard [::]:123
15 Mar 01:44:11 ntpd[19703]: Listen and drop on 1 v4wildcard 0.0.0.0:123
15 Mar 01:44:11 ntpd[19703]: Listen normally on 2 lo 127.0.0.1:123
15 Mar 01:44:11 ntpd[19703]: Listen normally on 3 eth0 192.168.71.13:123
15 Mar 01:44:11 ntpd[19703]: Listen normally on 4 lo [::1]:123
15 Mar 01:44:11 ntpd[19703]: Listen for broadcasts to 192.168.71.255 on 
interface #3 eth0
15 Mar 01:44:11 ntpd[19703]: Listening on routing socket on fd #22 for 
interface updates
15 Mar 01:44:12 ntpd[19703]: Soliciting pool server 204.2.134.164
15 Mar 01:44:14 ntpd[19703]: Soliciting pool server 216.229.0.49
15 Mar 01:44:14 ntpd[19703]: Soliciting pool server 95.81.173.155
15 Mar 01:44:15 ntpd[19703]: Soliciting pool server 193.30.35.11
15 Mar 01:45:17 ntpd[19703]: Soliciting pool server 69.164.202.202
15 Mar 01:45:18 ntpd[19703]: Soliciting pool server 216.229.4.69
15 Mar 01:45:19 ntpd[19703]: Soliciting pool server 5.9.83.106
15 Mar 01:45:20 ntpd[19703]: Soliciting pool server 23.31.21.164
15 Mar 01:46:23 ntpd[19703]: Soliciting pool server 81.169.199.94
15 Mar 01:46:23 ntpd[19703]: Soliciting pool server 50.205.244.24
15 Mar 01:46:25 ntpd[19703]: Soliciting pool server 81.94.123.17
15 Mar 01:46:25 ntpd[19703]: Soliciting pool server 67.205.162.81


Thanks David W.

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 

Re: ntp questions

[Gene Heskett]

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 1600 us, estimated error 1600 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 1600 us, estimated error 1600 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 1600 us, estimated error 1600 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 1600 us, estimated error 1600 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.35.103.128.88 2 u  953 1024  3770.2340.608   
0.526
gene@GO704:~$  

And a stretch machine:
gene@shop:~$ sudo ntpq -np
 remote   refid  st t when poll 

Re: ntp questions

[David Christensen]

On 2020-03-14 18:49, Gene Heskett wrote:

Greetings all;

In an attempt to reduce the load on my time servers and to mitigate the
jumps in system time that can play heck with timing errors of a running
LinuxCNc session, I have installed an ntp client on a raspbian buster,
and I think I have told it to listen to iburst from this machine.  All
my other machine are setup similar and appear to be working ok.

But the pi with an identical config is still not synching.
2 working machine symply say ok when asked for status, old wheezy
installs.
A gene@shop:~$ sudo /etc/init.d/ntp status
[ ok ] NTP server is running.

Which is typical when its all synched

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)
 Tasks: 2 (limit: 4033)
Memory: 936.0K
CGroup: /system.slice/ntp.service
└─16963 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 114:122

Mar 14 20:17:25 rpi4.coyote.den ntpd[16963]: leapsecond file
('/usr/share/zoneinfo/leap-seconds.list'): loaded,
expire=2020-06-28T00:00:00Z last=2017-01-01T00:00:00Z ofs=37
Mar 14 20:17:25 rpi4.coyote.den ntpd[16963]: Listen and drop on 0
v6wildcard [::]:123
Mar 14 20:17:25 rpi4.coyote.den ntpd[16963]: Listen and drop on 1
v4wildcard 0.0.0.0:123
Mar 14 20:17:25 rpi4.coyote.den ntpd[16963]: Listen normally on 2 lo
127.0.0.1:123
Mar 14 20:17:25 rpi4.coyote.den ntpd[16963]: Listen normally on 3 eth0
192.168.71.13:123
Mar 14 20:17:25 rpi4.coyote.den ntpd[16963]: Listen normally on 4 lo
[::1]:123
Mar 14 20:17:25 rpi4.coyote.den ntpd[16963]: Listening on routing socket
on fd #21 for interface updates
Mar 14 20:17:25 rpi4.coyote.den ntpd[16963]: Listen for broadcasts to
192.168.71.255 on interface #3 eth0
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?

Looking for ntp.conf diffs a grep -v '#' reports for a working machines
ntp.conf:
driftfile /var/lib/ntp/ntp.drift
statsdir /var/log/ntpstats/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
server 192.168.71.3 iburst
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
restrict 127.0.0.1
restrict ::1
disable auth
broadcastclient

while that same inverted grep on the pi reports:

driftfile /var/lib/ntp/ntp.drift
leapfile /usr/share/zoneinfo/leap-seconds.list
statsdir /var/log/ntpstats/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
server coyote.coyote.den iburst
restrict -4 default kod notrap nomodify nopeer noquery limited
restrict -6 default kod notrap nomodify nopeer noquery limited
restrict 127.0.0.1
restrict ::1
restrict source notrap nomodify noquery <-different, # it no change
broadcast 192.168.71.255
disable auth
broadcastclient

Thanks everybody.


Cheers, Gene Heskett


Have you tried installing ntpdate on the problem machine and rebooting?


David

Re: ntp questions

[David Wright]

On Sat 14 Mar 2020 at 21:49:43 (-0400), Gene Heskett wrote:
> 
> In an attempt to reduce the load on my time servers and to mitigate the 
> jumps in system time that can play heck with timing errors of a running 
> LinuxCNc session, I have installed an ntp client on a raspbian buster, 
> and I think I have told it to listen to iburst from this machine.  All 
> my other machine are setup similar and appear to be working ok.
> 
> But the pi with an identical config is still not synching.

Is this something to do with the Pi not having a hardware clock?
IOW when it boots up, it doesn't have a clue what time it is.

I've read that you should run   ntpd -g -q   on the Pi, having
first stopped its daemon/service (according to how you're
running it, sysvinit/systemd). This allows a time jump from
4004 BC or whatever it boots up at. Then restart the
daemon/service.

Cheers,
David.

Re: ntp questions

[Andy Smith]

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…

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

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

and

$ ntpq -np

?

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.

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

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.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting