[opensuse] two identical machines, ntp sync is different?
Well, I'm 99% certain they are identical - one is in a cupboard 100 meters away, the other is right here on my desk. They are tiny ARM boards, Nanopi Neo Air. The ntp config: # egrep -v '^#|^$' /etc/ntp.conf restrict -4 default notrap nomodify nopeer noquery restrict -6 default notrap nomodify nopeer noquery restrict 127.0.0.1 restrict ::1 driftfile /var/lib/ntp/drift/ntp.drift # path for drift file logfile /var/log/ntp # alternate log file keys /etc/ntp.keys # path for keys file trustedkey 1 # define trusted keys requestkey 1 # key (7) for accessing server variables controlkey 1 # key (6) for accessing server variables multicastclient ff05::101 The ntp.keys files are identical. They are connected to the same wifi, although not to the same access point. On "nano1": (shortened) # ntpq -pn remote refid st t ====================================== *192.168.2.254 .DCFa. 1 u +fe80::202:a5ff: 192.168.2.137 2 b On "nano2": (shortened) # ntpq -pn remote refid st t ===================================== x192.168.2.254 .DCFa. 1 u xfe80::202:a5ff: 192.168.2.137 2 b Apparently the 'x' means: "source false ticker" I don't recall ever seeing this before. It's not critical, I'm just curious. I'm surely missing something, anyone want to point out what it is? -- Per Jessen, Zürich (2.5°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
11.02.2019 21:50, Per Jessen пишет:
Well, I'm 99% certain they are identical - one is in a cupboard 100 meters away, the other is right here on my desk. They are tiny ARM boards, Nanopi Neo Air.
The ntp config:
# egrep -v '^#|^$' /etc/ntp.conf restrict -4 default notrap nomodify nopeer noquery restrict -6 default notrap nomodify nopeer noquery restrict 127.0.0.1 restrict ::1 driftfile /var/lib/ntp/drift/ntp.drift # path for drift file logfile /var/log/ntp # alternate log file keys /etc/ntp.keys # path for keys file trustedkey 1 # define trusted keys requestkey 1 # key (7) for accessing server variables controlkey 1 # key (6) for accessing server variables multicastclient ff05::101
The ntp.keys files are identical. They are connected to the same wifi, although not to the same access point.
On "nano1": (shortened)
# ntpq -pn remote refid st t ====================================== *192.168.2.254 .DCFa. 1 u +fe80::202:a5ff: 192.168.2.137 2 b
On "nano2": (shortened)
# ntpq -pn remote refid st t ===================================== x192.168.2.254 .DCFa. 1 u xfe80::202:a5ff: 192.168.2.137 2 b
Apparently the 'x' means:
"source false ticker"
I don't recall ever seeing this before. It's not critical, I'm just curious. I'm surely missing something, anyone want to point out what it is?
https://access.redhat.com/solutions/58025 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrei Borzenkov wrote:
11.02.2019 21:50, Per Jessen пишет:
Well, I'm 99% certain they are identical - one is in a cupboard 100 meters away, the other is right here on my desk. They are tiny ARM boards, Nanopi Neo Air.
The ntp config:
# egrep -v '^#|^$' /etc/ntp.conf restrict -4 default notrap nomodify nopeer noquery restrict -6 default notrap nomodify nopeer noquery restrict 127.0.0.1 restrict ::1 driftfile /var/lib/ntp/drift/ntp.drift # path for drift file logfile /var/log/ntp # alternate log file keys /etc/ntp.keys # path for keys file trustedkey 1 # define trusted keys requestkey 1 # key (7) for accessing server variables controlkey 1 # key (6) for accessing server variables multicastclient ff05::101
The ntp.keys files are identical. They are connected to the same wifi, although not to the same access point.
On "nano1": (shortened)
# ntpq -pn remote refid st t ====================================== *192.168.2.254 .DCFa. 1 u +fe80::202:a5ff: 192.168.2.137 2 b
On "nano2": (shortened)
# ntpq -pn remote refid st t ===================================== x192.168.2.254 .DCFa. 1 u xfe80::202:a5ff: 192.168.2.137 2 b
Apparently the 'x' means:
"source false ticker"
I don't recall ever seeing this before. It's not critical, I'm just curious. I'm surely missing something, anyone want to point out what it is?
Thanks Andrei - I don't think that's the situation I have. I know it looks different, but there is really only one time-server. Both boards get both addresses (ipv4 via dhcp, ipv6 via multicast). My main question is really - why are the two identical setups/boards seeing a different result? We have multiple machines working like this, no 'false ticker' anywhere else. -- Per Jessen, Zürich (1.0°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
Per Jessen wrote:
Thanks Andrei - I don't think that's the situation I have. I know it looks different, but there is really only one time-server. Both boards get both addresses (ipv4 via dhcp, ipv6 via multicast). My main question is really - why are the two identical setups/boards seeing a different result? We have multiple machines working like this, no 'false ticker' anywhere else.
Well. Very much a coincidence - this morning, shortly after writing the above, I received some new wifi aerials I'd ordered. The old ones are about 11cm long, the new ones are 19cm. To test if the threading was the same, I swapped the aerials. Time sync on nano2 now works fine. Reception quality? -- Per Jessen, Zürich (2.4°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
12.02.2019 11:41, Per Jessen пишет:
Per Jessen wrote:
Thanks Andrei - I don't think that's the situation I have. I know it looks different, but there is really only one time-server. Both
For ntp client it is still two servers and it has to chose between them. If both are too different, it has no criteria to do it.
boards get both addresses (ipv4 via dhcp, ipv6 via multicast). My main question is really - why are the two identical setups/boards seeing a different result? We have multiple machines working like this, no 'false ticker' anywhere else.
Well. Very much a coincidence - this morning, shortly after writing the above, I received some new wifi aerials I'd ordered. The old ones are about 11cm long, the new ones are 19cm. To test if the threading was the same, I swapped the aerials. Time sync on nano2 now works fine. Reception quality?
Yes, as servers themselves appear normal (as confirmed by other client) it must have been network conditions then. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/02/2019 08.30, Per Jessen wrote:
Andrei Borzenkov wrote:
11.02.2019 21:50, Per Jessen пишет:
Thanks Andrei - I don't think that's the situation I have. I know it looks different, but there is really only one time-server. Both boards get both addresses (ipv4 via dhcp, ipv6 via multicast). My main question is really - why are the two identical setups/boards seeing a different result? We have multiple machines working like this, no 'false ticker' anywhere else.
The thing is, with NTP you should really be using five servers to keep it happy. With one or two servers, it is better some other tool. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Carlos E. R. wrote:
On 12/02/2019 08.30, Per Jessen wrote:
Andrei Borzenkov wrote:
11.02.2019 21:50, Per Jessen пишет:
Thanks Andrei - I don't think that's the situation I have. I know it looks different, but there is really only one time-server. Both boards get both addresses (ipv4 via dhcp, ipv6 via multicast). My main question is really - why are the two identical setups/boards seeing a different result? We have multiple machines working like this, no 'false ticker' anywhere else.
The thing is, with NTP you should really be using five servers to keep it happy.
Carlos, please. I know very well what I am doing. One stratum 1 server is just right. -- Per Jessen, Zürich (4.2°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
On 12/02/2019 11.50, Per Jessen wrote:
Carlos E. R. wrote:
On 12/02/2019 08.30, Per Jessen wrote:
Andrei Borzenkov wrote:
11.02.2019 21:50, Per Jessen пишет:
Thanks Andrei - I don't think that's the situation I have. I know it looks different, but there is really only one time-server. Both boards get both addresses (ipv4 via dhcp, ipv6 via multicast). My main question is really - why are the two identical setups/boards seeing a different result? We have multiple machines working like this, no 'false ticker' anywhere else.
The thing is, with NTP you should really be using five servers to keep it happy.
Carlos, please. I know very well what I am doing. One stratum 1 server is just right.
Ok, ok! Don't get all worked up :-) I'm just citing from memory when I read the doc on ntp years ago. I'll google. <https://support.ntp.org/bin/view/Support/SelectingOffsiteNTPServers> 5.3.3. Upstream Time Server Quantity Many people wonder how many upstream time servers they should list in their NTP configuration file. The mathematics are complex, and fully understood by very few people. However, we can boil them down to some simple rules-of-thumb: If you list just one, there can be no question which will be considered to be "right" or "wrong". But if that one goes down, you are toast. With two, it is impossible to tell which one is better, because you don't have any other references to compare them with. This is actually the worst possible configuration -- you'd be better off using just one upstream time server and letting the clocks run free if that upstream were to die or become unreachable. With three servers, you have the minimum number of time sources needed to allow ntpd to dectect if one time source is a "falseticker". However ntpd will then be in the position of choosing from the two remaining sources.This configuration provides no redundancy. With at least four upstream servers, one (or more) can be a "falseticker", or just unreachable, and ntpd will have a sufficient number of sources to choose from. According to Brian Utterback, the math officially goes like this: While the general rule is for 2n+1 to protect against "n" falsetickers, this actually isn't true for the case where n=1. It actually takes 2 servers to produce a "candidate" time, which is really an interval. The winner is the shortest interval for which more than half (counting the two that define the interval) have an offset (+/- the dispersion) that lies on the interval and that contains the point of greatest overlap. So, in the case of four servers, the truechimer with the largest offset defines one end of the interval, the truechimer with the smallest offset defines the other end, and the third truechimer overlaps these two, with a overlap count of at least two and possibly three. The falseticker's interval will overlap few if any of these intervals (or it wouldn't be a falseticker) and will be eliminated. With only three servers, the interval defined by the two truechimers has no overlap with any other servers, but the interval defined by one of the truechimers and the falseticker overlaps the other truechimer, so this is the interval chosen, and thus the falseticker is still included. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Carlos E. R. wrote:
On 12/02/2019 11.50, Per Jessen wrote:
Carlos E. R. wrote:
On 12/02/2019 08.30, Per Jessen wrote:
Andrei Borzenkov wrote:
11.02.2019 21:50, Per Jessen пишет:
Thanks Andrei - I don't think that's the situation I have. I know it looks different, but there is really only one time-server. Both boards get both addresses (ipv4 via dhcp, ipv6 via multicast). My main question is really - why are the two identical setups/boards seeing a different result? We have multiple machines working like this, no 'false ticker' anywhere else.
The thing is, with NTP you should really be using five servers to keep it happy.
Carlos, please. I know very well what I am doing. One stratum 1 server is just right.
Ok, ok! Don't get all worked up :-)
I'm just citing from memory when I read the doc on ntp years ago. I'll google.
<https://support.ntp.org/bin/view/Support/SelectingOffsiteNTPServers>
5.3.3. Upstream Time Server Quantity
Many people wonder how many upstream time servers they should list in their NTP configuration file.
The rest does not apply. There is only one time server. As you can tell from the ntpq output I posted, it runs on a local network, as stratum 1, synchronised to a DCF77 source. -- Per Jessen, Zürich (4.4°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
On 12/02/2019 12.28, Per Jessen wrote:
Carlos E. R. wrote:
The rest does not apply. There is only one time server. As you can tell from the ntpq output I posted, it runs on a local network, as stratum 1, synchronised to a DCF77 source.
Ah, it is a time reference source. I missed that. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
participants (3)
-
Andrei Borzenkov -
Carlos E. R. -
Per Jessen