[opensuse] checking on ntpd
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I looked on google and several places tell to use "ntpstat" to verify the clock. Now, ntpstat is not available on openSUSE (I tried "osc se -s ntpstat" and "cnf ntpstat"). <https://www.cyberciti.biz/faq/linux-unix-bsd-is-ntp-client-working/> Sample outputs: synchronised to NTP server (149.20.54.20) at stratum 3 time correct to within 42 ms polling server every 1024 s Now, as ntpstat is nowhere to be found, how can I know what is the actual time difference between my computer clock and reality? No, ntpq doesn't say. - -- Cheers Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXhh+uxwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVENgAoIZ6uFAoUp+q/Pe0Z/QB HS05VKmEAJ9Kml4jOH3znQd0T+buqln1x/MH3Q== =ZvYR -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
Now, as ntpstat is nowhere to be found, how can I know what is the actual time difference between my computer clock and reality?
No, ntpq doesn't say.
When ntpq -pn indicates a synchronized client, there is no actual time difference between your computer clock and reality. (i.e. the upper stratum clock you have defined). -- Per Jessen, Zürich (11.4°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, Jan 10, 2020 at 5:03 PM Per Jessen <per@computer.org> wrote:
Carlos E. R. wrote:
Now, as ntpstat is nowhere to be found, how can I know what is the actual time difference between my computer clock and reality?
No, ntpq doesn't say.
When ntpq -pn indicates a synchronized client, there is no actual time difference between your computer clock and reality.
Of course there is, as "ntpq -pn" clearly says. Whether it is negligible or not depends on your goals. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrei Borzenkov wrote:
On Fri, Jan 10, 2020 at 5:03 PM Per Jessen <per@computer.org> wrote:
Carlos E. R. wrote:
Now, as ntpstat is nowhere to be found, how can I know what is the actual time difference between my computer clock and reality?
No, ntpq doesn't say.
When ntpq -pn indicates a synchronized client, there is no actual time difference between your computer clock and reality.
Of course there is, as "ntpq -pn" clearly says. Whether it is negligible or not depends on your goals.
Okay, yes of course that is true. I should have say that a "synchronised client" for me is equivalent to "no difference". -- Per Jessen, Zürich (9.4°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2020-01-10 09:03 AM, Per Jessen wrote:
Carlos E. R. wrote:
Now, as ntpstat is nowhere to be found, how can I know what is the actual time difference between my computer clock and reality?
No, ntpq doesn't say. When ntpq -pn indicates a synchronized client, there is no actual time difference between your computer clock and reality. (i.e. the upper stratum clock you have defined).
# ntpq -pn ntpq: read: Connection refused -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
On 2020-01-10 09:03 AM, Per Jessen wrote:
Carlos E. R. wrote:
Now, as ntpstat is nowhere to be found, how can I know what is the actual time difference between my computer clock and reality?
No, ntpq doesn't say. When ntpq -pn indicates a synchronized client, there is no actual time difference between your computer clock and reality. (i.e. the upper stratum clock you have defined).
# ntpq -pn ntpq: read: Connection refused
Hence your "status of ntpd" is "not running'. -- Per Jessen, Zürich (9.8°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2020-01-10 10:43 AM, Per Jessen wrote:
# ntpq -pn ntpq: read: Connection refused
Hence your "status of ntpd" is "not running'.
According to NTP Configuration, it was supposed to start on boot, but in Services Manager, it was shown as not running and start manually. I just started it and now get: # ntpq -pn No association ID's returned -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
On 2020-01-10 10:43 AM, Per Jessen wrote:
# ntpq -pn ntpq: read: Connection refused
Hence your "status of ntpd" is "not running'.
According to NTP Configuration, it was supposed to start on boot, but in Services Manager, it was shown as not running and start manually.
What does "systemctl status ntpd" say?
I just started it and now get: # ntpq -pn No association ID's returned
One of these: a) your config is faulty b) no connection to an acceptable server c) it takes time to synchronize. d) your machine is so way out of sync that ntpd won't sync it unless forced. (run ntpdate). -- Per Jessen, Zürich (9.1°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2020-01-10 10:57 AM, Per Jessen wrote:
What does "systemctl status ntpd" say?
Jan 10 10:48:56 linux systemd[1]: Starting NTP Server Daemon... Jan 10 10:48:56 linux ntpd[10075]: ntpd 4.2.8p13@1.3847-o (1): Starting Jan 10 10:48:56 linux ntpd[10075]: Command line: /usr/sbin/ntpd -p /var/run/ntp/ntpd.pid -g -u ntp:ntp -c /e> Jan 10 10:48:56 linux ntpd[10076]: proto: precision = 0.046 usec (-24) Jan 10 10:48:56 linux ntpd[10076]: basedate set to 2019-02-27 Jan 10 10:48:56 linux ntpd[10076]: gps base set to 2019-03-03 (week 2043) Jan 10 10:48:56 linux ntpd[10076]: switching logging to file /var/log/ntp Jan 10 10:48:56 linux start-ntpd[10067]: Starting network time protocol daemon (NTPD) Jan 10 10:48:56 linux systemd[1]: Started NTP Server Daemon.
d) your machine is so way out of sync that ntpd won't sync it unless forced. (run ntpdate). # ntpdate 10 Jan 11:03:43 ntpdate[25316]: no servers can be used, exiting
However, NTP is working. I can see the packets with Wireshark. I'm using my firewall as the source. Also, my computer time matches a clock that receives a signal from WWVB. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
On 2020-01-10 10:57 AM, Per Jessen wrote:
What does "systemctl status ntpd" say?
[snip log] That's only the log output, I would like to see the whole thing, like this: office31:~ # systemctl status ntpd ● ntpd.service - NTP Server Daemon Loaded: loaded (/usr/lib/systemd/system/ntpd.service; enabled; vendor preset: disabled) Drop-In: /run/systemd/generator/ntpd.service.d └─50-insserv.conf-$time.conf
d) your machine is so way out of sync that ntpd won't sync it unless forced. (run ntpdate). # ntpdate 10 Jan 11:03:43 ntpdate[25316]: no servers can be used, exiting
If you need to force a synch, you use "ntpdate <server>".
However, NTP is working. I can see the packets with Wireshark. I'm using my firewall as the source. Also, my computer time matches a clock that receives a signal from WWVB.
So eventually ntpq will produce some useful output too. -- Per Jessen, Zürich (9.2°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2020-01-10 11:15 AM, Per Jessen wrote:
James Knott wrote:
On 2020-01-10 10:57 AM, Per Jessen wrote:
What does "systemctl status ntpd" say? [snip log]
That's only the log output, I would like to see the whole thing, like this:
office31:~ # systemctl status ntpd ● ntpd.service - NTP Server Daemon Loaded: loaded (/usr/lib/systemd/system/ntpd.service; enabled; vendor preset: disabled) Drop-In: /run/systemd/generator/ntpd.service.d └─50-insserv.conf-$time.conf # systemctl status ntpd ● ntpd.service - NTP Server Daemon Loaded: loaded (/usr/lib/systemd/system/ntpd.service; enabled; vendor preset: disabled) Drop-In: /run/systemd/generator/ntpd.service.d └─50-insserv.conf-$time.conf Active: active (running) since Fri 2020-01-10 10:48:56 EST; 11min ago Docs: man:ntpd(1) Process: 10067 ExecStart=/usr/sbin/start-ntpd start (code=exited, status=0/SUCCESS) Main PID: 10076 (ntpd) Tasks: 2 (limit: 4915) CGroup: /system.slice/ntpd.service ├─10076 /usr/sbin/ntpd -p /var/run/ntp/ntpd.pid -g -u ntp:ntp -c /etc/ntp.conf └─10077 ntpd: asynchronous dns resolver
Jan 10 10:48:56 linux systemd[1]: Starting NTP Server Daemon... Jan 10 10:48:56 linux ntpd[10075]: ntpd 4.2.8p13@1.3847-o (1): Starting Jan 10 10:48:56 linux ntpd[10075]: Command line: /usr/sbin/ntpd -p /var/run/ntp/ntpd.pid -g -u ntp:ntp -c /e> Jan 10 10:48:56 linux ntpd[10076]: proto: precision = 0.046 usec (-24) Jan 10 10:48:56 linux ntpd[10076]: basedate set to 2019-02-27 Jan 10 10:48:56 linux ntpd[10076]: gps base set to 2019-03-03 (week 2043) Jan 10 10:48:56 linux ntpd[10076]: switching logging to file /var/log/ntp Jan 10 10:48:56 linux start-ntpd[10067]: Starting network time protocol daemon (NTPD) Jan 10 10:48:56 linux systemd[1]: Started NTP Server Daemon.
d) your machine is so way out of sync that ntpd won't sync it unless forced. (run ntpdate). # ntpdate 10 Jan 11:03:43 ntpdate[25316]: no servers can be used, exiting If you need to force a synch, you use "ntpdate <server>".
# ntpdate 172.16.0.1 10 Jan 11:24:47 ntpdate[11499]: adjust time server 172.16.0.1 offset -0.000036 sec
However, NTP is working. I can see the packets with Wireshark. I'm using my firewall as the source. Also, my computer time matches a clock that receives a signal from WWVB. So eventually ntpq will produce some useful output too.
I'm now taken to a ntpq prompt. I've tried some of the commands. Some like host work, but others such as sysinfo or sysstats return connection refused. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
# systemctl status ntpd ● ntpd.service - NTP Server Daemon Loaded: loaded (/usr/lib/systemd/system/ntpd.service; enabled;
When it wasn't running but clearly is enabled, you'll need to look at the ntpd logs to see why it stopped. Being too far out of sync is one option.
I'm now taken to a ntpq prompt. I've tried some of the commands. Some like host work, but others such as sysinfo or sysstats return connection refused.
For me "ntpq -pn" is the default, I rarely have reason to play with the rest of them. -- Per Jessen, Zürich (9.7°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/01/2020 17.59, James Knott wrote: | On 2020-01-10 11:46 AM, Per Jessen wrote: |> For me "ntpq -pn" is the default, I rarely have reason to play |> with the rest of them. | | Still getting connection refused. The configuration has to allow it. There was some mitigation to a vulnerability that disabled it. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXhjBsQAKCRC1MxgcbY1H 1ZLaAJ9FuWYw/xznp5cJU2QI5J9c9IV4WgCfeCpVgcfTQ3mWIpHBXFbY8FsECbg= =7L/B -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/01/2020 17.59, James Knott wrote: | On 2020-01-10 11:46 AM, Per Jessen wrote: |> For me "ntpq -pn" is the default, I rarely have reason to play |> with the rest of them. | | Still getting connection refused.
The configuration has to allow it. There was some mitigation to a vulnerability that disabled it.
Not on the local machine. The default config should certainly allow it. -- Per Jessen, Zürich (9.1°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/01/2020 19.36, Per Jessen wrote: | Carlos E. R. wrote:>> On 10/01/2020 17.59, James Knott wrote: |> | On 2020-01-10 11:46 AM, Per Jessen wrote: |> For me "ntpq -pn" |> is the default, I rarely have reason to play |> with the rest of |> them. | | Still getting connection refused. |> |> The configuration has to allow it. There was some mitigation to |> a vulnerability that disabled it. | | Not on the local machine. The default config should certainly | allow it. I know that the configuration can block the local as well, because it happened to me. What is exactly that configuration change, I don't remember. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXhjGrQAKCRC1MxgcbY1H 1Rf/AJwLJWjHNHQ5IdSr7AE1IxXtPHE+FwCbBHDAjutp/ACToj+rp1xL5F+1XdU= =OOU3 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/01/2020 19.36, Per Jessen wrote: | Carlos E. R. wrote:>> On 10/01/2020 17.59, James Knott wrote: |> | On 2020-01-10 11:46 AM, Per Jessen wrote: |> For me "ntpq -pn" |> is the default, I rarely have reason to play |> with the rest of |> them. | | Still getting connection refused. |> |> The configuration has to allow it. There was some mitigation to |> a vulnerability that disabled it. | | Not on the local machine. The default config should certainly | allow it.
I know that the configuration can block the local as well, because it happened to me.
Of course.
What is exactly that configuration change, I don't remember.
It is the "restrict" keyword. The default config is: restrict -4 default notrap nomodify nopeer noquery restrict -6 default notrap nomodify nopeer noquery # Local users may interrogate the ntp server more closely. restrict 127.0.0.1 restrict ::1 -- Per Jessen, Zürich (6.9°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/01/2020 10.34, Per Jessen wrote: | Carlos E. R. wrote: |> On 10/01/2020 19.36, Per Jessen wrote: | Carlos E. R. wrote:>> On |> 10/01/2020 17.59, James Knott wrote: |> | On 2020-01-10 11:46 AM, |> Per Jessen wrote: |> For me "ntpq -pn" |> is the default, I |> rarely have reason to play |> with the rest of |> them. | | Still |> getting connection refused. |> |> The configuration has to allow |> it. There was some mitigation to |> a vulnerability that disabled |> it. | | Not on the local machine. The default config should |> certainly | allow it. |> |> I know that the configuration can block the local as well, |> because it happened to me. | | Of course. | |> What is exactly that configuration change, I don't remember. | | It is the "restrict" keyword. The default config is: | | restrict -4 default notrap nomodify nopeer noquery restrict -6 | default notrap nomodify nopeer noquery # Local users may | interrogate the ntp server more closely. restrict 127.0.0.1 | restrict ::1 Thanks (mine is not default). Well, that is what he has to check he has. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXhmY2wAKCRC1MxgcbY1H 1VStAJ9RZ/l1U2RBMEMss84R1Ht42Wt9+QCdFJrGCEazcZ26KhPFjm3KtFTpcXQ= =tff9 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2020-01-10 10:57 AM, Per Jessen wrote:
What does "systemctl status ntpd" say?
Jan 10 10:48:56 linux systemd[1]: Starting NTP Server Daemon... Jan 10 10:48:56 linux ntpd[10075]: ntpd 4.2.8p13@1.3847-o (1): Starting Jan 10 10:48:56 linux ntpd[10075]: Command line: /usr/sbin/ntpd -p /var/run/ntp/ntpd.pid -g -u ntp:ntp -c /e> Jan 10 10:48:56 linux ntpd[10076]: proto: precision = 0.046 usec (-24) Jan 10 10:48:56 linux ntpd[10076]: basedate set to 2019-02-27 Jan 10 10:48:56 linux ntpd[10076]: gps base set to 2019-03-03 (week 2043) Jan 10 10:48:56 linux ntpd[10076]: switching logging to file /var/log/ntp Jan 10 10:48:56 linux start-ntpd[10067]: Starting network time protocol daemon (NTPD) Jan 10 10:48:56 linux systemd[1]: Started NTP Server Daemon.
d) your machine is so way out of sync that ntpd won't sync it unless forced. (run ntpdate). # ntpdate 10 Jan 11:03:43 ntpdate[25316]: no servers can be used, exiting
However, NTP is working. I can see the packets with Wireshark. I'm using my firewall as the source. Also, my computer time matches a clock that receives a signal from WWVB. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, Jan 10, 2020 at 4:40 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
I looked on google and several places tell to use "ntpstat" to verify the clock. Now, ntpstat is not available on openSUSE (I tried "osc se -s ntpstat" and "cnf ntpstat").
https://github.com/darkhelmet/ntpstat
<https://www.cyberciti.biz/faq/linux-unix-bsd-is-ntp-client-working/>
Sample outputs:
synchronised to NTP server (149.20.54.20) at stratum 3 time correct to within 42 ms polling server every 1024 s
Now, as ntpstat is nowhere to be found, how can I know what is the actual time difference between my computer clock and reality?
Define reality.
No, ntpq doesn't say.
Of course it does. Both poll interval and root dispersion which is what ntpstat prints. Here you have poll interval in seconds: host:~ # ntpq -np remote refid st t when poll reach delay offset jitter ============================================================================== *xx.xx.x.xx 88.212.196.95 5 u 1 64 377 19.177 -0.042 0.331 Here you have root dispersion (i.e. "precision") in milliseconds.: host:~ # ntpq -c 'rv 0 rootdisp' rootdisp=128.295 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/01/2020 15.15, Andrei Borzenkov wrote:
On Fri, Jan 10, 2020 at 4:40 PM Carlos E. R. <> wrote:
Hi,
I looked on google and several places tell to use "ntpstat" to verify the clock. Now, ntpstat is not available on openSUSE (I tried "osc se -s ntpstat" and "cnf ntpstat").
So in openSUSE one has to build it on our own. I wonder why, when so many documents say to use it. :-? Ok, I compiled it, thanks.
<https://www.cyberciti.biz/faq/linux-unix-bsd-is-ntp-client-working/>
Sample outputs:
synchronised to NTP server (149.20.54.20) at stratum 3 time correct to within 42 ms polling server every 1024 s
Now, as ntpstat is nowhere to be found, how can I know what is the actual time difference between my computer clock and reality?
Define reality.
GPS :-)
No, ntpq doesn't say.
Of course it does. Both poll interval and root dispersion which is what ntpstat prints.
Here you have poll interval in seconds:
host:~ # ntpq -np remote refid st t when poll reach delay offset jitter
==============================================================================
*xx.xx.x.xx 88.212.196.95 5 u 1 64 377 19.177 -0.042 0.331 I don't know how to get from there "your clock is 45 mS off". And there is one line per server, so I don't know which is the one. I do know which one it is using as the upstream reference, yes, but ntp knows how much "off" is that one from "reality". I don't.
Here you have root dispersion (i.e. "precision") in milliseconds.:
host:~ # ntpq -c 'rv 0 rootdisp' rootdisp=128.295
Ok, that's better. It is 128 mS off, right? On my 24*7 miniserver: Isengard:~ # ntpstat ; ntpq -c 'rv 0 rootdisp' synchronised to NTP server (194.80.204.184) at stratum 2 time correct to within 34 ms polling server every 1024 s rootdisp=6.888 Isengard:~ # ntpstat ; ntpq -c 'rv 0 rootdisp' synchronised to NTP server (194.80.204.184) at stratum 2 time correct to within 35 ms polling server every 1024 s rootdisp=7.128 Isengard:~ # My desktop: Telcontar:~ # ntpstat ; ntpq -c 'rv 0 rootdisp' synchronised to NTP server (85.199.214.102) at stratum 2 time correct to within 26 ms polling server every 1024 s rootdisp=4.773 Telcontar:~ # ntpstat ; ntpq -c 'rv 0 rootdisp' synchronised to NTP server (85.199.214.102) at stratum 2 time correct to within 26 ms polling server every 1024 s rootdisp=4.788 Telcontar:~ # Results do not match. But frankly, ntpstat yields a result far easier to read. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 2020-01-10 10:11 AM, Carlos E. R. wrote:
Define reality.
GPS :-)
That's only accurate to within microseconds. Let me know when you get within a Planck time. ;-) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
On my 24*7 miniserver:
Isengard:~ # ntpstat ; ntpq -c 'rv 0 rootdisp' synchronised to NTP server (194.80.204.184) at stratum 2 time correct to within 34 ms polling server every 1024 s rootdisp=6.888 Isengard:~ # ntpstat ; ntpq -c 'rv 0 rootdisp' synchronised to NTP server (194.80.204.184) at stratum 2 time correct to within 35 ms polling server every 1024 s rootdisp=7.128 Isengard:~ #
My desktop:
Telcontar:~ # ntpstat ; ntpq -c 'rv 0 rootdisp' synchronised to NTP server (85.199.214.102) at stratum 2 time correct to within 26 ms polling server every 1024 s rootdisp=4.773 Telcontar:~ # ntpstat ; ntpq -c 'rv 0 rootdisp' synchronised to NTP server (85.199.214.102) at stratum 2 time correct to within 26 ms polling server every 1024 s rootdisp=4.788 Telcontar:~ #
Results do not match.
I guess this is the Linux version of "a man with one watch always knows what time it is. A man with two watches is never sure" :-) -- Per Jessen, Zürich (9.1°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2020-01-10 10:53 AM, Per Jessen wrote:
I guess this is the Linux version of "a man with one watch always knows what time it is. A man with two watches is never sure":-)
With NTP, the recommendation is at least 3 sources, as with 2, if one is wrong, you don't know which one. I have my firewall/router configured for 4. You can specify up to 4 pool.ntp.org servers, by adding a number, such as 0., 1., 2., or 3. before pool.ntp.org. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
On 2020-01-10 10:53 AM, Per Jessen wrote:
I guess this is the Linux version of "a man with one watch always knows what time it is. A man with two watches is never sure":-)
With NTP, the recommendation is at least 3 sources, as with 2, if one is wrong, you don't know which one. I have my firewall/router configured for 4.
You can specify up to 4 pool.ntp.org servers, by adding a number, such as 0., 1., 2., or 3. before pool.ntp.org.
We use DF77 which is sourced from PTB Braunschweig. -- Per Jessen, Zürich (9.2°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2020-01-10 11:12 AM, Per Jessen wrote:
We use DF77 which is sourced from PTB Braunschweig.
Here are a couple from Canada. CHU is a time and frequency broadcast station, on a couple of short wave bands and NRC is Canada's National Research Council. time.nrc.ca time.chu.nrc.ca -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/01/2020 16.59, James Knott wrote:
On 2020-01-10 10:53 AM, Per Jessen wrote:
I guess this is the Linux version of "a man with one watch always knows what time it is. A man with two watches is never sure":-)
With NTP, the recommendation is at least 3 sources, as with 2, if one is wrong, you don't know which one. I have my firewall/router configured for 4.
But if your internal desktop machine is using ntp, it also need 4 sources.
You can specify up to 4 pool.ntp.org servers, by adding a number, such as 0., 1., 2., or 3. before pool.ntp.org.
You can specify country. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 2020-01-10 01:28 PM, Carlos E. R. wrote:
On 10/01/2020 16.59, James Knott wrote:
On 2020-01-10 10:53 AM, Per Jessen wrote:
I guess this is the Linux version of "a man with one watch always knows what time it is. A man with two watches is never sure":-)
With NTP, the recommendation is at least 3 sources, as with 2, if one is wrong, you don't know which one. I have my firewall/router configured for 4.
But if your internal desktop machine is using ntp, it also need 4 sources.
For internal devices, I just use 1, my firewall.
You can specify up to 4 pool.ntp.org servers, by adding a number, such as 0., 1., 2., or 3. before pool.ntp.org.
You can specify country.
Pool.ntp.org will connect to servers according to where you are. If I ping those addresses, I'll generally see servers in the Toronto, Ontario area, which is where I live. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/01/2020 19.47, James Knott wrote: | On 2020-01-10 01:28 PM, Carlos E. R. wrote: |> On 10/01/2020 16.59, James Knott wrote: |>> On 2020-01-10 10:53 AM, Per Jessen wrote: |>>> I guess this is the Linux version of "a man with one watch |>>> always knows what time it is. A man with two watches is never |>>> sure":-) |>> |>> With NTP, the recommendation is at least 3 sources, as with 2, |>> if one is wrong, you don't know which one. I have my |>> firewall/router configured for 4. |> |> But if your internal desktop machine is using ntp, it also need 4 |> sources. | | For internal devices, I just use 1, my firewall. And that can make ntp to abort and ntpq to fail. You have to use some other daemon instead with just one clock source. |> |>> |>> You can specify up to 4 pool.ntp.org servers, by adding a |>> number, such as 0., 1., 2., or 3. before pool.ntp.org. |> |> You can specify country. |> | | Pool.ntp.org will connect to servers according to where you are. | If I ping those addresses, I'll generally see servers in the | Toronto, Ontario area, which is where I live. Me, I specify a dozen servers, on Spain, Portugal, France... etc. The daemon will choose which to actually use. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXhjHhQAKCRC1MxgcbY1H 1a6pAJoDCg13XkMi5V6gppBwac33aZIQlwCfYCdihgQxsAAcgAsztcrE2UrHuWY= =Z6CG -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, 10 Jan 2020 19:50:47 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/01/2020 19.47, James Knott wrote: | On 2020-01-10 01:28 PM, Carlos E. R. wrote: |> On 10/01/2020 16.59, James Knott wrote: |>> On 2020-01-10 10:53 AM, Per Jessen wrote: |>>> I guess this is the Linux version of "a man with one watch |>>> always knows what time it is. A man with two watches is never |>>> sure":-) |>> |>> With NTP, the recommendation is at least 3 sources, as with 2, |>> if one is wrong, you don't know which one. I have my |>> firewall/router configured for 4. |> |> But if your internal desktop machine is using ntp, it also need 4 |> sources. | | For internal devices, I just use 1, my firewall.
And that can make ntp to abort and ntpq to fail. You have to use some other daemon instead with just one clock source.
|> |>> |>> You can specify up to 4 pool.ntp.org servers, by adding a |>> number, such as 0., 1., 2., or 3. before pool.ntp.org. |> |> You can specify country. |> | | Pool.ntp.org will connect to servers according to where you are. | If I ping those addresses, I'll generally see servers in the | Toronto, Ontario area, which is where I live.
Me, I specify a dozen servers, on Spain, Portugal, France... etc. The daemon will choose which to actually use.
Why do you seem to care so much about your clock source? In the worst case, your PC/device will run on its internal clock and will slowly drift. Not a major problem. Once upon a time I worked with a telco setting up an ATM network in London. Their time source was in a rack with five slots. Slot 1 was a GPS card. Slot 2 (backup) was a GPS card. Slot 3 (backup's backup etc) was a GPS card. Slot 4 was a GPS card. Slot 5 was an atomic clock. What they most cared about was keeping the same time as everybody else. Only in extremis did they care about keeping something working. But the requirements for timekeeping in an ATM network are orders of magnitude above what I need, or any other mortal as far as I can see. My ntp.conf has what I think is the default: server 0.opensuse.pool.ntp.org iburst server 1.opensuse.pool.ntp.org iburst server 2.opensuse.pool.ntp.org iburst server 3.opensuse.pool.ntp.org iburst -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2020-01-10 02:55 PM, Dave Howorth wrote:
Once upon a time I worked with a telco setting up an ATM network in London. Their time source was in a rack with five slots. Slot 1 was a GPS card. Slot 2 (backup) was a GPS card. Slot 3 (backup's backup etc) was a GPS card. Slot 4 was a GPS card. Slot 5 was an atomic clock.
Many years ago, I had something to do with a clock for the old "T1" TDM timing, which used the Loran C signal to provide the time base. However, that was for the signal clock, not time of day. In my work, a few months ago, I saw a requirement for NTP that was clearly written by someone who didn't understand it. This was for a transit system, where a PPP (Public Private Partnership) is building a new line. The requirement, from the transit company said the PPP company was to use the existing NTP server, but if it failed, they were to switch over their (PPP) server. Apparently, whoever wrote that didn't understand peering, multiple sources, etc. or that redundancy and fallback were all built into NTP. The PPP network has 2 GPS receivers which, at stratum 0, would already be more precise than the stratum 1 coming from the transit company. Also, since NTP is supposed to be traceable back to International Atomic Time, there should be no discrepancy between the stratum 0 sources. Then they have to devise some means to detect failures etc.. As I said, someone doesn't know what they're talking about. I'd expect the proper configuration would be to peer the 2 PPP stratum 1 servers and client/server from the transit company stratum 1 servers to PPP stratum 1. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2020-01-10 at 19:55 -0000, Dave Howorth wrote:
On 10/01/2020 19.47, James Knott wrote: | On 2020-01-10 01:28 PM, Carlos E. R. wrote:
|>> number, such as 0., 1., 2., or 3. before pool.ntp.org. |> |> You can specify country. |> | | Pool.ntp.org will connect to servers according to where you are. | If I ping those addresses, I'll generally see servers in the | Toronto, Ontario area, which is where I live.
Me, I specify a dozen servers, on Spain, Portugal, France... etc. The daemon will choose which to actually use.
Why do you seem to care so much about your clock source? In the worst case, your PC/device will run on its internal clock and will slowly drift. Not a major problem.
Once upon a time I worked with a telco setting up an ATM network in London. Their time source was in a rack with five slots. Slot 1 was a GPS card. Slot 2 (backup) was a GPS card. Slot 3 (backup's backup etc) was a GPS card. Slot 4 was a GPS card. Slot 5 was an atomic clock.
I worked with a telco startup, and their reference clock, if purchased, was a quartz xtal inside an oven (to keep at a precise constant temperature, so no random drift). Pretty expensive. Design prior to GPS. Machine (5ESS) did not have any internet connection. I don't know if they added that later (GPS clock). At the time I knew those details, their clock was a simple quartz (default) and we set it up with a simple "date" command in unix :-D I suppose later they did something, but I did not get to know.
What they most cared about was keeping the same time as everybody else.
Same as me.
Only in extremis did they care about keeping something working. But the requirements for timekeeping in an ATM network are orders of magnitude above what I need, or any other mortal as far as I can see. My ntp.conf has what I think is the default:
server 0.opensuse.pool.ntp.org iburst server 1.opensuse.pool.ntp.org iburst server 2.opensuse.pool.ntp.org iburst server 3.opensuse.pool.ntp.org iburst
And I have more because I have seen servers of the pool in Spain, usually volunteers, to fail. And have four of them fail simultaneously, which is why I define more. Because I have seen many fail. The daemon is clever enough to decide and choose. Look: Isengard:~ # ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== LOCAL(0) .LOCL. 10 l 28d 64 0 0.000 0.000 0.000 #hora.ngn.rima-t 172.20.47.7 5 u 155 1024 377 13.202 1.309 0.466 <-- My ISP, I think - -Telcontar.valin 85.199.*.* 2 u 88 1024 377 0.321 -2.098 0.457 <-- My desktop machine - -ntp.redimadrid. 193.147.*.* 2 u 531 1024 377 13.275 -0.082 0.234 - -scott.red.uv.es 66.78.*.* 2 u 181 1024 377 22.782 -0.025 0.536 - -bjaaland.red.uv 66.78.*.* 2 u 164 1024 377 22.760 -0.089 0.630 +162.159.*.* 10.40.*.* 3 u 1025 1024 377 12.061 -1.148 0.539 +23.141.*.*.b 212.51.*.* 2 u 645 1024 377 38.604 -0.156 0.625 - -dedibox.demonge 145.238.*.* 2 u 89 1024 375 30.542 0.482 0.697 #electra.pinklem 192.36.*.* 2 u 152 1024 377 40.157 -3.077 0.363 #smtp.irtech.ch 162.23.*.* 2 u 253 1024 377 48.507 -3.071 0.496 - -ns3.stoneartpro 193.52.*.* 2 u 246 1024 377 26.988 -0.341 0.504 *194.80.*.* .GPS. 1 u 14 64 377 54.970 -1.153 0.078 - -178.255.*.* 194.80.*.* 2 u 45 1024 377 17.523 1.163 0.587 Isengard:~ # ^ | \-- code Code Message T Description 0 sel_reject discarded as not valid (TEST10-TEST13) 1 sel_falsetick x discarded by intersection algorithm 2 sel_excess . discarded by table overflow (not used) 3 sel_outlyer - discarded by the cluster algorithm 4 sel_candidate + included by the combine algorithm 5 sel_backup # backup (more than tos maxclock sources) 6 sel_sys.peer * system peer 7 sel_pps.peer o PPS peer (when the prefer peer is valid) As you can see, several are put as backup (#). Six are discarded (-); that's a high percent. The daemon is clever :-) Interestingly, the desktop machine refuses (-) my server machine: "discarded by the cluster algorithm". remote refid st t when poll reach delay offset jitter ============================================================================== LOCAL(0) .LOCL. 10 l 10h 64 0 0.000 0.000 0.000 - -Isengard.valino 194.80.*.* 2 u 865 1024 377 0.303 2.111 0.399 Also interestingly, the IP reported for the LAN peer is different in both machines: Telcontar.valin 85.199.*.* Isengard.valino 194.80.*.* which were the external IPs at the time of startup, I guess. The daemon is not clever here, does not update the IPs. - -- Cheers, Carlos E. R. (from openSUSE 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXhjz5Rwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVxjQAn3uUJGBAv/cD5gRU4zPe xAXRdAn4AJ9m2Uv2SMrhMKlgwp3/ps5uvPn8Tg== =6UZn -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
And I have more because I have seen servers of the pool in Spain, usually volunteers, to fail. And have four of them fail simultaneously, which is why I define more. Because I have seen many fail. The daemon is clever enough to decide and choose.
According to www.pool.ntp.org, Spain has 22 servers: https://www.pool.ntp.org/zone/es Given the size of the country, that is not a lot, but probably sufficient. -- Per Jessen, Zürich (7.5°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/01/2020 10.53, Per Jessen wrote: | Carlos E. R. wrote: | |> And I have more because I have seen servers of the pool in |> Spain, usually volunteers, to fail. And have four of them fail |> simultaneously, which is why I define more. Because I have seen |> many fail. The daemon is clever enough to decide and choose. | | According to www.pool.ntp.org, Spain has 22 servers: | | https://www.pool.ntp.org/zone/es | | Given the size of the country, that is not a lot, but probably | sufficient. Sure. I did not check how many there are (I didn't know it was possible to know), but I occasionally have hit several failing on daemon startup, enough to make it bail out. So I forced variance of countries and a large list. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXhmdlgAKCRC1MxgcbY1H 1RNAAJ43Q87VQqnCsK0GD4GW6bcgrluc2ACffYnpBWW0aUB+xwgzTrgPPSJEQis= =ZNcO -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/01/2020 10.53, Per Jessen wrote: | Carlos E. R. wrote: | |> And I have more because I have seen servers of the pool in |> Spain, usually volunteers, to fail. And have four of them fail |> simultaneously, which is why I define more. Because I have seen |> many fail. The daemon is clever enough to decide and choose. | | According to www.pool.ntp.org, Spain has 22 servers: | | https://www.pool.ntp.org/zone/es | | Given the size of the country, that is not a lot, but probably | sufficient.
Sure. I did not check how many there are (I didn't know it was possible to know), but I occasionally have hit several failing on daemon startup, enough to make it bail out.
Just define your local clock as dummy, stratum 10. -- Per Jessen, Zürich (7.6°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/01/2020 10.53, Per Jessen wrote: | Carlos E. R. wrote: | |> And I have more because I have seen servers of the pool in |> Spain, usually volunteers, to fail. And have four of them fail |> simultaneously, which is why I define more. Because I have seen |> many fail. The daemon is clever enough to decide and choose. | | According to www.pool.ntp.org, Spain has 22 servers: | | https://www.pool.ntp.org/zone/es | | Given the size of the country, that is not a lot, but probably | sufficient.
Sure. I did not check how many there are (I didn't know it was possible to know), but I occasionally have hit several failing on daemon startup, enough to make it bail out.
Just define your local clock as dummy, stratum 10.
Local, unsynched clock: server 127.127.1.0 fudge 127.127.1.0 stratum 10 -- Per Jessen, Zürich (8.6°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/01/2020 11.20, Per Jessen wrote: | Carlos E. R. wrote: |> On 11/01/2020 10.53, Per Jessen wrote: | Carlos E. R. wrote: | |> |> And I have more because I have seen servers of the pool in |> |> Spain, usually volunteers, to fail. And have four of them fail |> |> simultaneously, which is why I define more. Because I have seen |> |> many fail. The daemon is clever enough to decide and choose. |> | | According to www.pool.ntp.org, Spain has 22 servers: | | |> https://www.pool.ntp.org/zone/es | | Given the size of the |> country, that is not a lot, but probably | sufficient. |> |> Sure. I did not check how many there are (I didn't know it was |> possible to know), but I occasionally have hit several failing |> on daemon startup, enough to make it bail out. | | Just define your local clock as dummy, stratum 10. Yeah, and then get several seconds error (I checked). I prefer more entries. The load on the servers and my machine is negligible, it just uses 4 or 5 after boot. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXhmy+AAKCRC1MxgcbY1H 1RBPAKCLWGfUxcuchqde7Ns5sggf7NElgQCfX6ZKLUC0fT6zTczkAhV8HVIy0Fg= =TbTe -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/01/2020 11.20, Per Jessen wrote: | Carlos E. R. wrote: |> On 11/01/2020 10.53, Per Jessen wrote: | Carlos E. R. wrote: | |> |> And I have more because I have seen servers of the pool in |> |> Spain, usually volunteers, to fail. And have four of them fail |> |> simultaneously, which is why I define more. Because I have seen |> |> many fail. The daemon is clever enough to decide and choose. |> | | According to www.pool.ntp.org, Spain has 22 servers: | | |> https://www.pool.ntp.org/zone/es | | Given the size of the |> country, that is not a lot, but probably | sufficient. |> |> Sure. I did not check how many there are (I didn't know it was |> possible to know), but I occasionally have hit several failing |> on daemon startup, enough to make it bail out. | | Just define your local clock as dummy, stratum 10.
Yeah, and then get several seconds error (I checked).
Yes of course, it is not meant for regular operation. It is the last-ditch option, only meant for that situation where no other server can be reached, temporarily. Used to be the default in openSUSE, btw. Fiddling with multiple servers would be too much effort for me - for a single PC or a small network with no local time source, I would probably just add the local and pool.ntp.org. -- Per Jessen, Zürich (7.0°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/01/2020 12.42, Per Jessen wrote:
Carlos E. R. wrote:
On 11/01/2020 11.20, Per Jessen wrote: | Carlos E. R. wrote: |> On 11/01/2020 10.53, Per Jessen wrote: | Carlos E. R. wrote: | |> |> And I have more because I have seen servers of the pool in |> |> Spain, usually volunteers, to fail. And have four of them fail |> |> simultaneously, which is why I define more. Because I have seen |> |> many fail. The daemon is clever enough to decide and choose. |> | | According to www.pool.ntp.org, Spain has 22 servers: | | |> https://www.pool.ntp.org/zone/es | | Given the size of the |> country, that is not a lot, but probably | sufficient. |> |> Sure. I did not check how many there are (I didn't know it was |> possible to know), but I occasionally have hit several failing |> on daemon startup, enough to make it bail out. | | Just define your local clock as dummy, stratum 10.
Yeah, and then get several seconds error (I checked).
Yes of course, it is not meant for regular operation. It is the last-ditch option, only meant for that situation where no other server can be reached, temporarily. Used to be the default in openSUSE, btw.
Fiddling with multiple servers would be too much effort for me - for a single PC or a small network with no local time source, I would probably just add the local and pool.ntp.org.
I use the pool, no complications: server 127.127.1.0 # local clock (LCL) - I did not write these two entries fudge 127.127.1.0 stratum 10 # LCL is unsynchronized server hora.ngn.rima-tde.net # my ISP server telcontar.valinor iburst # my desktop - perhaps I should remove this one; done server 0.opensuse.pool.ntp.org iburst server 1.opensuse.pool.ntp.org iburst #server 2.opensuse.pool.ntp.org iburst #server 3.opensuse.pool.ntp.org iburst server 0.pool.ntp.org server 1.pool.ntp.org server 2.pool.ntp.org server 3.pool.ntp.org server 0.ch.pool.ntp.org server 0.fr.pool.ntp.org server 0.uk.pool.ntp.org server 0.es.pool.ntp.org server 1.ch.pool.ntp.org server 1.fr.pool.ntp.org server 1.uk.pool.ntp.org server 1.es.pool.ntp.org It is no complication at all. Copy paste. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXhm2xQAKCRC1MxgcbY1H 1ZzmAJ4osRzFtMrsbKIKcBbbZC8hM6tR9ACfYnjyx29e24PdiUuYrw6EVA2zg1c= =tRST -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 1/11/20 1:51 PM, Carlos E. R. wrote:
It is no complication at all. Copy paste.
- as in : "Switzerland — ch.pool.ntp.org To use this specific pool zone, add the following to your ntp.conf file: server 0.ch.pool.ntp.org server 1.ch.pool.ntp.org server 2.ch.pool.ntp.org server 3.ch.pool.ntp.org In most cases it's best to use pool.ntp.org " ..... rgds -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
ellanios82 wrote:
On 1/11/20 1:51 PM, Carlos E. R. wrote:
It is no complication at all. Copy paste.
- as in :
"Switzerland — ch.pool.ntp.org To use this specific pool zone, add the following to your ntp.conf file:
server 0.ch.pool.ntp.org server 1.ch.pool.ntp.org server 2.ch.pool.ntp.org server 3.ch.pool.ntp.org In most cases it's best to use pool.ntp.org "
Right, except when you are Carlos and the Spanish pool isn't good enough :-) Anyway, we have a local time reference. -- Per Jessen, Zürich (7.2°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 1/11/20 3:17 PM, Per Jessen wrote:
and the Spanish pool isn't good enough :-)
Anyway, we have a local time reference
- & , around here , nano-seconds don't matter : mah wife's inbuilt chronometer . . . 1/2 an hour , plus or minus, is of no importance .... rgds -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/01/2020 14.17, Per Jessen wrote: | ellanios82 wrote: | |> On 1/11/20 1:51 PM, Carlos E. R. wrote: |>> It is no complication at all. Copy paste. |>> |>> |> - as in : |> |> "Switzerland — ch.pool.ntp.org To use this specific pool zone, |> add the following to your ntp.conf file: |> |> server 0.ch.pool.ntp.org server 1.ch.pool.ntp.org server |> 2.ch.pool.ntp.org server 3.ch.pool.ntp.org That's what I use. I have: server 0.ch.pool.ntp.org server 1.ch.pool.ntp.org |> In most cases it's best to use pool.ntp.org " I also use that: server 0.pool.ntp.org server 1.pool.ntp.org | Right, except when you are Carlos and the Spanish pool isn't good | enough :-) | | Anyway, we have a local time reference. I simply introduce variance :-) - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXhoH2gAKCRC1MxgcbY1H 1cbDAKCZcXSajsD6EwGm52N4XsEfPiuUugCfWwme0wQo6aRC03wDgJcd66cV0IA= =KBvq -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
I simply introduce variance :-)
Yes, but needlessly. -- Per Jessen, Zürich (4.4°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/01/2020 18.58, Per Jessen wrote: | Carlos E. R. wrote: | |> I simply introduce variance :-) | | Yes, but needlessly. No, it is not. I said that prior to doing this I saw ntpd failing to start because it would not find reliable peers. In one of my posts in this thread I listed peers of my server, and most entries are marked "rejected". The excess are marked backup. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXhoWowAKCRC1MxgcbY1H 1dKBAJ9+gg9zNKCYxeaZJptLzoCYDblNHwCfQ4K3MueQ8N1afGPSrWEe5P2ztOY= =U9b4 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/01/2020 18.58, Per Jessen wrote: | Carlos E. R. wrote: | |> I simply introduce variance :-) | | Yes, but needlessly.
No, it is not. I said that prior to doing this I saw ntpd failing to start because it would not find reliable peers.
Yes, agree, that is of course a problem when there are 22 servers and none of them work or is reachable. -- Per Jessen, Zürich (4.8°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/01/2020 11.47, Per Jessen wrote: | Carlos E. R. wrote: |> On 11/01/2020 18.58, Per Jessen wrote: | Carlos E. R. wrote: | |> |> I simply introduce variance :-) | | Yes, but needlessly. |> |> No, it is not. I said that prior to doing this I saw ntpd failing |> to start because it would not find reliable peers. | | Yes, agree, that is of course a problem when there are 22 servers | and none of them work or is reachable. You misunderstand. It was a problem when there were 4 server defined in my config and 3 or 4 failed (and of course not every day). It is not a problem if I define 20 and 4 fail. Even if 15 fail. Defining 20 pool servers is a solution to an actual problem I detected. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXhsJNAAKCRC1MxgcbY1H 1aPqAJ4tN+626tQ2ut1lvpsmQhCba7vTRACfU8W+bzum1XhD2xOzH7UcLTyvTLA= =chVp -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/01/2020 11.47, Per Jessen wrote: | Carlos E. R. wrote: |> On 11/01/2020 18.58, Per Jessen wrote: | Carlos E. R. wrote: | |> |> I simply introduce variance :-) | | Yes, but needlessly. |> |> No, it is not. I said that prior to doing this I saw ntpd failing |> to start because it would not find reliable peers. | | Yes, agree, that is of course a problem when there are 22 servers | and none of them work or is reachable.
You misunderstand.
It was a problem when there were 4 server defined in my config and 3 or 4 failed (and of course not every day). It is not a problem if I define 20 and 4 fail. Even if 15 fail.
Defining 20 pool servers is a solution to an actual problem I detected.
I meant - there are 22 servers under es.pool.ntp.org. Each query gives back four of those, in some round-robin fashion. -- Per Jessen, Zürich (6.6°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/01/2020 13.09, Per Jessen wrote: | Carlos E. R. wrote: |> On 12/01/2020 11.47, Per Jessen wrote: | Carlos E. R. wrote: |> |> On 11/01/2020 18.58, Per Jessen wrote: | Carlos E. R. wrote: | |> |> |> I simply introduce variance :-) | | Yes, but needlessly. |> |> |> No, it is not. I said that prior to doing this I saw ntpd |> failing |> to start because it would not find reliable peers. | | |> Yes, agree, that is of course a problem when there are 22 |> servers | and none of them work or is reachable. |> |> You misunderstand. |> |> It was a problem when there were 4 server defined in my config |> and 3 or 4 failed (and of course not every day). It is not a |> problem if I define 20 and 4 fail. Even if 15 fail. |> |> Defining 20 pool servers is a solution to an actual problem I |> detected. | | I meant - there are 22 servers under es.pool.ntp.org. Each query | gives back four of those, in some round-robin fashion. Right, and I was unlucky to hit the four that were not working that moment. It just happened, more than once... so I took measures. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXhsNhgAKCRC1MxgcbY1H 1ZHlAJ9Frs1Z/iRvgAJMxfx3HptlfjcYawCeK2q8WOkGdoHKsd0EeZ69uKiGGv0= =hBrl -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
server 127.127.1.0 # local clock (LCL) - I did not write these two entries fudge 127.127.1.0 stratum 10 # LCL is unsynchronized
Those two are from the old default ntp config, They are now commented out, but I don't know when that was done. -- Per Jessen, Zürich (4.2°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Dave Howorth wrote:
Once upon a time I worked with a telco setting up an ATM network in London. Their time source was in a rack with five slots. Slot 1 was a GPS card. Slot 2 (backup) was a GPS card. Slot 3 (backup's backup etc) was a GPS card. Slot 4 was a GPS card. Slot 5 was an atomic clock.
What they most cared about was keeping the same time as everybody else.
Yes, that is also a key reason for me. The other is to keep all our own (local and remote) machines on the same time, with reasonable accuracy. Makes troubleshooting so much easier :-) -- Per Jessen, Zürich (6.8°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/01/2020 10.43, Per Jessen wrote: | Dave Howorth wrote: | |> Once upon a time I worked with a telco setting up an ATM network |> in London. Their time source was in a rack with five slots. Slot |> 1 was a GPS card. Slot 2 (backup) was a GPS card. Slot 3 |> (backup's backup etc) was a GPS card. Slot 4 was a GPS card. Slot |> 5 was an atomic clock. |> |> What they most cared about was keeping the same time as |> everybody else. | | Yes, that is also a key reason for me. The other is to keep all | our own (local and remote) machines on the same time, with | reasonable accuracy. Makes troubleshooting so much easier :-) It makes the timestamps in the log files across machines reliable. You notice that easily in email headers. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXhmZrwAKCRC1MxgcbY1H 1fD/AJ9TQm2oCd7fRk1+S7+Pc8+xPr+W8ACfXdZpTm5KBiKYMtPiiPgHZYbi1xY= =O9I5 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/01/2020 19.47, James Knott wrote: | On 2020-01-10 01:28 PM, Carlos E. R. wrote: |> On 10/01/2020 16.59, James Knott wrote: |>> On 2020-01-10 10:53 AM, Per Jessen wrote: |>>> I guess this is the Linux version of "a man with one watch |>>> always knows what time it is. A man with two watches is never |>>> sure":-) |>> |>> With NTP, the recommendation is at least 3 sources, as with 2, |>> if one is wrong, you don't know which one. I have my |>> firewall/router configured for 4. |> |> But if your internal desktop machine is using ntp, it also need 4 |> sources. | | For internal devices, I just use 1, my firewall.
And that can make ntp to abort and ntpq to fail. You have to use some other daemon instead with just one clock source.
I use a setup much like James', just one source. It is our DNS an DHCP server which is also the DCF77 receiver. In the last 15 years, it has not made ntp abort. -- Per Jessen, Zürich (6.9°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/01/2020 10.40, Per Jessen wrote: | Carlos E. R. wrote: |> On 10/01/2020 19.47, James Knott wrote: | On 2020-01-10 01:28 |> PM, Carlos E. R. wrote: |> On 10/01/2020 16.59, James Knott |> wrote: |>> On 2020-01-10 10:53 AM, Per Jessen wrote: |>>> I guess |> this is the Linux version of "a man with one watch |>>> always |> knows what time it is. A man with two watches is never |>>> |> sure":-) |>> |>> With NTP, the recommendation is at least 3 |> sources, as with 2, |>> if one is wrong, you don't know which |> one. I have my |>> firewall/router configured for 4. |> |> But |> if your internal desktop machine is using ntp, it also need 4 |> |> sources. | | For internal devices, I just use 1, my firewall. |> |> And that can make ntp to abort and ntpq to fail. You have to use |> some other daemon instead with just one clock source. | | I use a setup much like James', just one source. It is our DNS an | DHCP server which is also the DCF77 receiver. | | In the last 15 years, it has not made ntp abort. You must have a setting for that, as the docs say that ntpd needs 3 peers minimum. When I tried once, mine aborted. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXhmZTQAKCRC1MxgcbY1H 1WqbAJ9AuyHUd02XtgISKcsQz1JTtAN5fQCeL6o8K1GBpTwfobpXPNZFEkId37Y= =Gv3o -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
|> And that can make ntp to abort and ntpq to fail. You have to use |> some other daemon instead with just one clock source. | | I use a setup much like James', just one source. It is our DNS an | DHCP server which is also the DCF77 receiver. | | In the last 15 years, it has not made ntp abort.
You must have a setting for that, as the docs say that ntpd needs 3 peers minimum.
I think you may want to re-read that doc. It is perfectly reasonable to have only one source, why shouldn't it be? Our NTP setup instructions (worked out long ago) say: a) remove default servers b) add "multicastclient ff05::101" c) update key. A test system I recently dup'ed to Leap 15.1: office31:~ # ntpq -pn remote refid st t when poll reach delay offset jitter ============================================================================== 127.127.1.0 .LOCL. 10 l 352d 64 0 0.000 0.000 0.000 *192.168.2.254 .DCFa. 1 u 42 1024 377 0.279 -2.159 1.543 +fe80::202:a5ff: 192.168.2.254 2 b 5 16 377 24.836 8.207 0.007 -- Per Jessen, Zürich (7.2°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/01/2020 11.07, Per Jessen wrote:
Carlos E. R. wrote:
|> And that can make ntp to abort and ntpq to fail. You have to use |> some other daemon instead with just one clock source. | | I use a setup much like James', just one source. It is our DNS an | DHCP server which is also the DCF77 receiver. | | In the last 15 years, it has not made ntp abort.
You must have a setting for that, as the docs say that ntpd needs 3 peers minimum.
I think you may want to re-read that doc. It is perfectly reasonable to have only one source, why shouldn't it be?
I think not, because there is no checking if that clock is correct. No redundancy. I mean, the clients can not know if that single clock is correct.
Our NTP setup instructions (worked out long ago) say:
a) remove default servers b) add "multicastclient ff05::101" c) update key.
A test system I recently dup'ed to Leap 15.1:
office31:~ # ntpq -pn remote refid st t when poll reach delay offset jitter ============================================================================== 127.127.1.0 .LOCL. 10 l 352d 64 0 0.000 0.000 0.000 *192.168.2.254 .DCFa. 1 u 42 1024 377 0.279 -2.159 1.543 +fe80::202:a5ff: 192.168.2.254 2 b 5 16 377 24.836 8.207 0.007 stratum 1? Wow.
This is how my desktop sees my server: - -Isengard.valino 194.80.*.* 2 u 138 1024 177 0.330 1.920 0.962 but it prefers an external reference: *85.199.*.* .GPS. 1 u 55 64 377 42.500 -0.859 0.163 That may be an important difference, my local server is stratum 2, yours is 1. I don't actually care, even 3 would be good enough. I don't know why I have a stratum 1 reference in the pool. No reverse IP, network is Colocker-Data-Centre, GB. There is an actual physical address in "whois", but I'm not printing it here. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXhm1UwAKCRC1MxgcbY1H 1U0iAJ4ne6dFHjhxTAxXwHQns07HEmZ90QCdFCjsF+TGkxjNet1RBImAiXxqPvI= =f07s -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/01/2020 11.07, Per Jessen wrote:
Carlos E. R. wrote:
|> And that can make ntp to abort and ntpq to fail. You have to use |> some other daemon instead with just one clock source. | | I use a setup much like James', just one source. It is our DNS an | DHCP server which is also the DCF77 receiver. | | In the last 15 years, it has not made ntp abort.
You must have a setting for that, as the docs say that ntpd needs 3 peers minimum.
I think you may want to re-read that doc. It is perfectly reasonable to have only one source, why shouldn't it be?
I think not, because there is no checking if that clock is correct. No redundancy. I mean, the clients can not know if that single clock is correct.
In our setup, we have a local time server synched to DCF77, peering with metas.ch (Swiss Federal). When you have a local time source, you only need one.
This is how my desktop sees my server:
- -Isengard.valino 194.80.*.* 2 u 138 1024 177 0.330 1.920 0.962
but it prefers an external reference:
*85.199.*.* .GPS. 1 u 55 64 377 42.500 -0.859 0.163
A GPS clock somewhere.
That may be an important difference, my local server is stratum 2, yours is 1. I don't actually care, even 3 would be good enough. I don't know why I have a stratum 1 reference in the pool.
Simply because someone is providing it.
No reverse IP, network is Colocker-Data-Centre, GB. There is an actual physical address in "whois", but I'm not printing it here.
It's all public information anyway. -- Per Jessen, Zürich (7.0°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/01/2020 13.04, Per Jessen wrote: | Carlos E. R. wrote: |> On 11/01/2020 11.07, Per Jessen wrote: |>> Carlos E. R. wrote: |>> |>>> |> And that can make ntp to abort and ntpq to fail. You have |>>> to use |> some other daemon instead with just one clock |>>> source. | | I use a setup much like James', just one source. |>>> It is our DNS an | DHCP server which is also the DCF77 |>>> receiver. | | In the last 15 years, it has not made ntp |>>> abort. |>>> |>>> You must have a setting for that, as the docs say that ntpd |>>> needs 3 peers minimum. |>> |>> I think you may want to re-read that doc. It is perfectly |>> reasonable to have only one source, why shouldn't it be? |> |> I think not, because there is no checking if that clock is |> correct. No redundancy. I mean, the clients can not know if that |> single clock is correct. | | In our setup, we have a local time server synched to DCF77, peering | with metas.ch (Swiss Federal). When you have a local time source, | you only need one. That's a crucial data point :-) Still, I'm paranoid and would define 3 sources :-D | | |> This is how my desktop sees my server: |> |> - -Isengard.valino 194.80.*.* 2 u 138 1024 177 |> 0.330 1.920 0.962 |> |> but it prefers an external reference: |> |> *85.199.*.* .GPS. 1 u 55 64 377 42.500 |> -0.859 0.163 | | A GPS clock somewhere. GB. | |> That may be an important difference, my local server is stratum |> 2, yours is 1. I don't actually care, even 3 would be good |> enough. I don't know why I have a stratum 1 reference in the |> pool. | | Simply because someone is providing it. | |> No reverse IP, network is Colocker-Data-Centre, GB. There is an |> actual physical address in "whois", but I'm not printing it |> here. | | It's all public information anyway. Still... - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXhm+jAAKCRC1MxgcbY1H 1RibAJ94YzSMlJ5xJujo47XgaHWZUT4zCQCglYSMLRit123H9+hvQymUC2hpVyY= =ATg+ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2020-01-11 07:04 AM, Per Jessen wrote:
In our setup, we have a local time server synched to DCF77, peering with metas.ch (Swiss Federal).
Are you actually peering? Or just using them as another source. Peering means sync goes both ways. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
On 2020-01-11 07:04 AM, Per Jessen wrote:
In our setup, we have a local time server synched to DCF77, peering with metas.ch (Swiss Federal).
Are you actually peering? Or just using them as another source. Peering means sync goes both ways.
Yes, I was actually wondering that myself. I didn't do that config personally, but I can tell it was specifically enabled/configured. Looking at the ntpq output, it is marked 'x' = "false ticker" ?? # ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== *GENERIC(0) .DCFa. 0 l 44 64 377 0.000 1.205 1.144 LOCAL(0) .LOCL. 10 l 59 64 377 0.000 0.000 0.001 xmetasntp13.admi .MRS. 1 u 654 1024 377 4.588 -10.753 0.203 192.168.7.255 .BCST. 16 u - 16 0 0.000 0.000 0.001 ff05::101 .MCST. 16 u - 16 0 0.000 0.000 0.001 TBH, I have my doubts about that peer setup. -- Per Jessen, Zürich (4.6°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2020-01-12 05:56 AM, Per Jessen wrote:
TBH, I have my doubts about that peer setup.
If I'm not mistaken, a peer has to be set up at both ends. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
On 2020-01-12 05:56 AM, Per Jessen wrote:
TBH, I have my doubts about that peer setup.
If I'm not mistaken, a peer has to be set up at both ends.
Yes, that sounds likely. Looking at a trace, on our end we are in "active peer" mode, the metas server responds with "passive peer". -- Per Jessen, Zürich (6.6°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 1/12/20 2:56 AM, Per Jessen wrote:
James Knott wrote:
In our setup, we have a local time server synched to DCF77, peering with metas.ch (Swiss Federal). Are you actually peering? Or just using them as another source. Peering means sync goes both ways. Yes, I was actually wondering that myself. I didn't do that config
On 2020-01-11 07:04 AM, Per Jessen wrote: personally, but I can tell it was specifically enabled/configured. Looking at the ntpq output, it is marked 'x' = "false ticker" ??
# ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== *GENERIC(0) .DCFa. 0 l 44 64 377 0.000 1.205 1.144 LOCAL(0) .LOCL. 10 l 59 64 377 0.000 0.000 0.001 xmetasntp13.admi .MRS. 1 u 654 1024 377 4.588 -10.753 0.203 192.168.7.255 .BCST. 16 u - 16 0 0.000 0.000 0.001 ff05::101 .MCST. 16 u - 16 0 0.000 0.000 0.001
TBH, I have my doubts about that peer setup.
Peering is kind of a misnomer... In terms of ntp, a peer is simply the server you get time from. It's NOT bidirectional unless the time server you get time from has been told to get time from you. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2020-01-12 09:41 AM, Bruce Ferrell wrote:
Peering is kind of a misnomer... In terms of ntp, a peer is simply the server you get time from. It's NOT bidirectional unless the time server you get time from has been told to get time from you.
That's a bit different from what it says here and elsewhere: http://docs.ruckuswireless.com/fastiron/08.0.80/fastiron-08080-managementgui... My understanding, as in that article, is the peers backup each other, while getting their time from a better source. For example, you can buy GPS receiver/NTP stratum 1 servers. You could then peer multiple of these. They'd normally get their time from the stratum 0 GPS receiver and provide stratum 1 to the network. However, if the GPS receiver fails, then the stratum 1 server will get it's time from another. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/01/2020 16.36, James Knott wrote:
On 2020-01-12 09:41 AM, Bruce Ferrell wrote:
Peering is kind of a misnomer... In terms of ntp, a peer is simply the server you get time from. It's NOT bidirectional unless the time server you get time from has been told to get time from you.
That's a bit different from what it says here and elsewhere:
http://docs.ruckuswireless.com/fastiron/08.0.80/fastiron-08080-managementgui...
My understanding, as in that article, is the peers backup each other, while getting their time from a better source. For example, you can buy GPS receiver/NTP stratum 1 servers. You could then peer multiple of these. They'd normally get their time from the stratum 0 GPS receiver and provide stratum 1 to the network. However, if the GPS receiver fails, then the stratum 1 server will get it's time from another.
Notice that in this definition, you "get or may get the time from your peers" and they "get or may get the time from you and the others as their peers" In that sense it is bidirectional if each one set the others as peers, and each one defines himself as server. O perhaps server only for a limited set of IPs. Active/passive I don't understand what may be exactly. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 2020-01-12 11:50 AM, Carlos E. R. wrote:
In that sense it is bidirectional if each one set the others as peers, and each one defines himself as server. O perhaps server only for a limited set of IPs.
That's why I said a peer has to be configured at both ends. With normal client/server, only the client is configured to use the server. There is no matching configuration on the server. Also, IIRC, the client also becomes a server. It least that's the way it used to be in openSUSE. I haven't checked recently, but I did that when I was using it as my firewall. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/01/2020 17.56, James Knott wrote: | On 2020-01-12 11:50 AM, Carlos E. R. wrote: |> In that sense it is bidirectional if each one set the others as |> peers, and each one defines himself as server. O perhaps server |> only for a limited set of IPs. | | That's why I said a peer has to be configured at both ends. With | normal client/server, only the client is configured to use the | server. There is no matching configuration on the server. Also, | IIRC, the client also becomes a server. It least that's the way | it used to be in openSUSE. I haven't checked recently, but I did | that when I was using it as my firewall. I think the client needs to be told to listen to become a server; otherwise requests would be banging the firewall. I'm unsure if that is the keyword "restrict". I have forgotten how, I configured ntp long ago... - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXhtT4wAKCRC1MxgcbY1H 1UBlAJ9m+kK3XqdWheZOBxwy5NmRZPFNzACcDL51P8P4kE3UHZknvOGlVT9SRHM= =2+dW -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2020-01-12 12:14 PM, Carlos E. R. wrote:
| That's why I said a peer has to be configured at both ends. With | normal client/server, only the client is configured to use the | server. There is no matching configuration on the server. Also, | IIRC, the client also becomes a server. It least that's the way | it used to be in openSUSE. I haven't checked recently, but I did | that when I was using it as my firewall.
I think the client needs to be told to listen to become a server; otherwise requests would be banging the firewall. I'm unsure if that is the keyword "restrict".
The firewall rules wouldn't apply, as they're on the WAN side and the NTP requests from the firewall would go out just as usual. The LAN side is where the server has to listen for requests. IIRC, the only option for the server was multicast. Unicast just worked. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/01/2020 18.18, James Knott wrote:
On 2020-01-12 12:14 PM, Carlos E. R. wrote:
| That's why I said a peer has to be configured at both ends. With | normal client/server, only the client is configured to use the | server. There is no matching configuration on the server. Also, | IIRC, the client also becomes a server. It least that's the way | it used to be in openSUSE. I haven't checked recently, but I did | that when I was using it as my firewall.
I think the client needs to be told to listen to become a server; otherwise requests would be banging the firewall. I'm unsure if that is the keyword "restrict".
The firewall rules wouldn't apply, as they're on the WAN side and the NTP requests from the firewall would go out just as usual. The LAN side is where the server has to listen for requests. IIRC, the only option for the server was multicast. Unicast just worked.
HAS to. But the LAN network interface is the same one that is connected to the gateway. If I say: Telcontar: server Isengard.valinor iburst Isengard: server telcontar.valinor iburst both are on the lan, and each one has the one as peer. And they get listed: Isengard:~ # ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== LOCAL(0) .LOCL. 10 l 30d 64 0 0.000 0.000 0.000 #Telcontar.valin 85.199.*.* 2 u 1043 1024 377 0.298 -3.923 0.855 cer@Telcontar:~> ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== LOCAL(0) .LOCL. 10 l 7h 64 0 0.000 0.000 0.000 - -Isengard.valino 194.80.*.* 2 u 308 1024 377 0.315 3.890 0.260 All that correct and as intended. Now, I also have: server 0.opensuse.pool.ntp.org iburst and my machine queries that one. Can someone outside query me? Perhaps 0.opensuse.pool.ntp.org? No, they would bang on my firewall. Both on the router firewall and my machine firewall, IIRC. By the way, my ISP time server is stratum 5, worse than me (I am, albeit unintentionally, st 2): Isengard:~ # ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== LOCAL(0) .LOCL. 10 l 30d 64 0 0.000 0.000 0.000 #hora.ngn.rima-t 172.20.47.7 5 u 186 1024 377 12.877 -0.739 0.257 server hora.ngn.rima-tde.net - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXhtcxwAKCRC1MxgcbY1H 1UKZAKCJctHa+N4xvYNMDMKPlsODB1Cn3gCdGd3/mxyRTEfNNocqvle57WvGvPs= =G8bL -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2020-01-12 12:52 PM, Carlos E. R. wrote:
HAS to. But the LAN network interface is the same one that is connected to the gateway.
You must have a funny firewall/router. I was referring to my previous firewall, which was built on openSUSE. One interface was the WAN side and the other, LAN. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/01/2020 19.24, James Knott wrote:
On 2020-01-12 12:52 PM, Carlos E. R. wrote:
HAS to. But the LAN network interface is the same one that is connected to the gateway.
You must have a funny firewall/router.
Just the ISP supplied box "for free". They call them "router"; but they have a firewall, router, switch, wifi access point; some models also have an USB port or two, and serve files via ftp, and other features.
I was referring to my previous firewall, which was built on openSUSE. One interface was the WAN side and the other, LAN.
I always had an ISP router. Well, not when I had a modem. And the initial ADSL router came with the firewall disabled by default, now that I remember. In all those cases, my machines connected to the LAN also have their own firewall (SuSEfirewall2 and one firewalld). In SuSEfirewalld, the ntp port is open only to packets coming from the 192.168.1.* network. So ntp going in from internet hits one firewall, one NAT, and another firewall. Am I paranoid for running a firewall on all my capable machines, inside my LAN? Probably. I do not trust much the ISP supplied router+firewall. And in the case of the laptops, they can be connected directly to internet via mobile phone tethering. Well, with GNAT + phone NAT. capable machines: I mean that, for example, the printer doesn't have a firewall. Pity. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Carlos E. R. wrote:
both are on the lan, and each one has the one as peer. And they get listed:
Isengard:~ # ntpq -p remote refid st t when poll reach delay offset jitter
==============================================================================
LOCAL(0) .LOCL. 10 l 30d 64 0 0.000 0.000 0.000 #Telcontar.valin 85.199.*.* 2 u 1043 1024 377 0.298 -3.923 # 0.855
cer@Telcontar:~> ntpq -p remote refid st t when poll reach delay offset jitter
==============================================================================
LOCAL(0) .LOCL. 10 l 7h 64 0 0.000 0.000 0.000 - -Isengard.valino 194.80.*.* 2 u 308 1024 377 0.315 3.890 0.260
Just wondering - here you _do_ have a local unsynched refclock defined. Earlier I thought you said you didn't want that. Also, those two systems are not synchronized ? (or did you snip the output?)
Can someone outside query me? Perhaps 0.opensuse.pool.ntp.org? No, they would bang on my firewall. Both on the router firewall and my machine firewall, IIRC.
Not unless you have port forwarding enabled for 123/udp in your NAT setup. -- Per Jessen, Zürich (3.4°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 13/01/2020 10.53, Per Jessen wrote:
Carlos E. R. wrote:
both are on the lan, and each one has the one as peer. And they get listed:
Isengard:~ # ntpq -p remote refid st t when poll reach delay offset jitter
==============================================================================
LOCAL(0) .LOCL. 10 l 30d 64 0 0.000 0.000 0.000
#Telcontar.valin 85.199.*.* 2 u 1043 1024 377 0.298 -3.923 0.855
cer@Telcontar:~> ntpq -p remote refid st t when poll reach delay offset jitter
==============================================================================
LOCAL(0) .LOCL. 10 l 7h 64 0 0.000 0.000 0.000
- -Isengard.valino 194.80.*.* 2 u 308 1024 377 0.315 3.890 0.260
Just wondering - here you _do_ have a local unsynched refclock defined. Earlier I thought you said you didn't want that.
The entry is there, of course, it is a default. But I do not want it actually used. The result is the same if the daemon bails out or if it uses the internal clock: a bad clock.
Also, those two systems are not synchronized ? (or did you snip the output?)
Snipped, of course.
Can someone outside query me? Perhaps 0.opensuse.pool.ntp.org? No, they would bang on my firewall. Both on the router firewall and my machine firewall, IIRC.
Not unless you have port forwarding enabled for 123/udp in your NAT setup.
Right. I don't even know if they try, though. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Carlos E. R. wrote:
Can someone outside query me? Perhaps 0.opensuse.pool.ntp.org? No, they would bang on my firewall. Both on the router firewall and my machine firewall, IIRC.
Not unless you have port forwarding enabled for 123/udp in your NAT setup.
Right.
I don't even know if they try, though.
Oh yes, they do. Look up "ntp amplification attack". -- Per Jessen, Zürich (4.3°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13/01/2020 11.59, Per Jessen wrote: | Carlos E. R. wrote: | |>> |>>> Can someone outside query me? Perhaps |>>> 0.opensuse.pool.ntp.org? No, they would bang on my firewall. |>>> Both on the router firewall and my machine firewall, IIRC. |>> |>> Not unless you have port forwarding enabled for 123/udp in |>> your NAT setup. |> |> Right. |> |> I don't even know if they try, though. | | Oh yes, they do. Look up "ntp amplification attack". I heard of it, did not look up the details. <https://www.imperva.com/learn/application-security/ntp-amplification/> In the most basic type of NTP amplification attack, an attacker repeatedly sends the “get monlist” request to an NTP server, while spoofing the requesting server’s IP address to that of the victim server. The NTP server responds by sending the list to the spoofed IP address. This response is considerably larger than the request, amplifying the amount of traffic directed at the target server and ultimately leading to a degradation of service for legitimate requests. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXhxnBAAKCRC1MxgcbY1H 1eJFAJ0eWzUcrGkW9wdaGM6sl3GCRs6Q5gCgksUuslnSIvcxEMEqZyq9J3tzDiM= =prP+ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/01/2020 17.56, James Knott wrote: | On 2020-01-12 11:50 AM, Carlos E. R. wrote: |> In that sense it is bidirectional if each one set the others as |> peers, and each one defines himself as server. O perhaps server |> only for a limited set of IPs. | | That's why I said a peer has to be configured at both ends. With | normal client/server, only the client is configured to use the | server. There is no matching configuration on the server. Also, | IIRC, the client also becomes a server. It least that's the way | it used to be in openSUSE. I haven't checked recently, but I did | that when I was using it as my firewall.
I think the client needs to be told to listen to become a server; otherwise requests would be banging the firewall. I'm unsure if that is the keyword "restrict".
An ntp daemon will always listen, "restrict" is for limiting access, yes. -- Per Jessen, Zürich (2.8°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/01/2020 18.21, Per Jessen wrote: | Carlos E. R. wrote: |> On 12/01/2020 17.56, James Knott wrote: | On 2020-01-12 11:50 AM, |> Carlos E. R. wrote: |> In that sense it is bidirectional if each |> one set the others as |> peers, and each one defines himself as |> server. O perhaps server |> only for a limited set of IPs. | | |> That's why I said a peer has to be configured at both ends. |> With | normal client/server, only the client is configured to use |> the | server. There is no matching configuration on the server. |> Also, | IIRC, the client also becomes a server. It least that's |> the way | it used to be in openSUSE. I haven't checked recently, |> but I did | that when I was using it as my firewall. |> |> I think the client needs to be told to listen to become a |> server; otherwise requests would be banging the firewall. I'm |> unsure if that is the keyword "restrict". | | An ntp daemon will always listen, "restrict" is for limiting | access, yes. Ah, so it always listens, unless restricted. Not as I thought. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXhtdVgAKCRC1MxgcbY1H 1UNaAJoCVhpHyKLQX90pBRwJ2ca0KxELxQCePEycAJsDrahH9xcnAh7pLcJTVtM= =q55R -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
10.01.2020 18:11, Carlos E. R. пишет:
Here you have poll interval in seconds:
host:~ # ntpq -np remote refid st t when poll reach delay offset jitter
==============================================================================
*xx.xx.x.xx 88.212.196.95 5 u 1 64 377 19.177 -0.042 0.331
I don't know how to get from there "your clock is 45 mS off".
Sorry? I said "here is poll interval" and poll interval *is* per server. If you have multiple servers each one can be polled with different interval. I did not say "here is your offset from reality".
And there is one line per server, so I don't know which is the one. I do know which one it is using as the upstream reference, yes, but ntp knows how much "off" is that one from "reality". I don't.
NTP does not know it. You misunderstand information that you get from NTP.
Here you have root dispersion (i.e. "precision") in milliseconds.:
host:~ # ntpq -c 'rv 0 rootdisp' rootdisp=128.295
Ok, that's better. It is 128 mS off, right?
No. It means that NTP cannot estimate correct time with better accuracy than 128ms. System may be having exactly correct time but NTP in this configuration has no way to reliably know it.
On my 24*7 miniserver:
Isengard:~ # ntpstat ; ntpq -c 'rv 0 rootdisp' synchronised to NTP server (194.80.204.184) at stratum 2 time correct to within 34 ms polling server every 1024 s rootdisp=6.888 Isengard:~ # ntpstat ; ntpq -c 'rv 0 rootdisp' synchronised to NTP server (194.80.204.184) at stratum 2 time correct to within 35 ms polling server every 1024 s rootdisp=7.128 Isengard:~ #
My desktop:
Telcontar:~ # ntpstat ; ntpq -c 'rv 0 rootdisp' synchronised to NTP server (85.199.214.102) at stratum 2 time correct to within 26 ms polling server every 1024 s rootdisp=4.773 Telcontar:~ # ntpstat ; ntpq -c 'rv 0 rootdisp' synchronised to NTP server (85.199.214.102) at stratum 2 time correct to within 26 ms polling server every 1024 s rootdisp=4.788 Telcontar:~ #
Results do not match. But frankly, ntpstat yields a result far easier to read.
Well, so it is quite possible that there are multiple implementations of ntpstat and each implementation chose to use different variables. Which basically makes usefulness of it exactly nil. It is also possible that ntpstat takes root dispersion from current synchronization source. My command gives "system variable", and I am not sure whether it is the same. You would need to check per-peer variables. I am also not sure what you need this information for. You seem to misinterpret result anyway.
On 10/01/2020 17.46, Andrei Borzenkov wrote:
10.01.2020 18:11, Carlos E. R. пишет:
Here you have poll interval in seconds:
host:~ # ntpq -np remote refid st t when poll reach delay offset jitter
==============================================================================
*xx.xx.x.xx 88.212.196.95 5 u 1 64 377 19.177 -0.042
0.331
I don't know how to get from there "your clock is 45 mS off".
Sorry? I said "here is poll interval" and poll interval *is* per server. If you have multiple servers each one can be polled with different interval.
Ok, but I'm not that interested in the poll interval.
I did not say "here is your offset from reality".
But that is my question.
And there is one line per server, so I don't know which is the one. I do know which one it is using as the upstream reference, yes, but ntp knows how much "off" is that one from "reality". I don't.
NTP does not know it. You misunderstand information that you get from NTP.
NTP knows, because I have seen it somewhere, what is the difference between the local clok and the "correct time", and the margin of error for that figure.
Here you have root dispersion (i.e. "precision") in milliseconds.:
host:~ # ntpq -c 'rv 0 rootdisp' rootdisp=128.295
Ok, that's better. It is 128 mS off, right?
No. It means that NTP cannot estimate correct time with better accuracy than 128ms. System may be having exactly correct time but NTP in this configuration has no way to reliably know it.
Ok, I understand.
On my 24*7 miniserver:
Isengard:~ # ntpstat ; ntpq -c 'rv 0 rootdisp' synchronised to NTP server (194.80.204.184) at stratum 2 time correct to within 34 ms polling server every 1024 s rootdisp=6.888 Isengard:~ # ntpstat ; ntpq -c 'rv 0 rootdisp' synchronised to NTP server (194.80.204.184) at stratum 2 time correct to within 35 ms polling server every 1024 s rootdisp=7.128 Isengard:~ #
My desktop:
Telcontar:~ # ntpstat ; ntpq -c 'rv 0 rootdisp' synchronised to NTP server (85.199.214.102) at stratum 2 time correct to within 26 ms polling server every 1024 s rootdisp=4.773 Telcontar:~ # ntpstat ; ntpq -c 'rv 0 rootdisp' synchronised to NTP server (85.199.214.102) at stratum 2 time correct to within 26 ms polling server every 1024 s rootdisp=4.788 Telcontar:~ #
Results do not match. But frankly, ntpstat yields a result far easier to read.
Well, so it is quite possible that there are multiple implementations of ntpstat and each implementation chose to use different variables. Which basically makes usefulness of it exactly nil.
It is also possible that ntpstat takes root dispersion from current synchronization source. My command gives "system variable", and I am not sure whether it is the same. You would need to check per-peer variables.
I am also not sure what you need this information for. You seem to misinterpret result anyway.
What I want to know is how correct is the local clock time, how big is the difference between the (estimated) difference between my local time and a GPS clock. If it says "time correct to within 26 ms" that is exactly what I want to know. So if I do: Isengard:~ # ntpstat ; ntpq -c 'rv 0 rootdisp' ; echo ; date --iso-8601=ns synchronised to NTP server (194.80.204.184) at stratum 2 time correct to within 33 ms polling server every 1024 s rootdisp=5.464 2020-01-10T19:38:30,476296732+01:00 Isengard:~ # I know that I can trust the seconds to be 0.479±0.033 Seconds. If it says "within one second" I know that there is some little problem, perhaps it is catching up. I know that "time correct to within 26 ms" should estimate my difference and my error and that of the chain of references clocks used till it gets to a GPS clock out there, and I hope the command does that correctly. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 01/10/2020 07:40 AM, Carlos E. R. wrote:
Hi,
I looked on google and several places tell to use "ntpstat" to verify the clock. Now, ntpstat is not available on openSUSE (I tried "osc se -s ntpstat" and "cnf ntpstat").
<https://www.cyberciti.biz/faq/linux-unix-bsd-is-ntp-client-working/>
Sample outputs:
synchronised to NTP server (149.20.54.20) at stratum 3 time correct to within 42 ms polling server every 1024 s
Now, as ntpstat is nowhere to be found, how can I know what is the actual time difference between my computer clock and reality?
No, ntpq doesn't say.
In addition to ntpq, systemd now provides time and date control and client ntp time sync, e.g. https://wiki.archlinux.org/index.php/System_time sntp daemon (client side only) https://wiki.archlinux.org/index.php/Systemd-timesyncd As long as you are not functioning as a ntp server, systemd does a pretty good job. -- David C. Rankin, J.D.,P.E.
participants (8)
-
Andrei Borzenkov -
Bruce Ferrell -
Carlos E. R. -
Dave Howorth -
David C. Rankin -
ellanios82 -
James Knott -
Per Jessen