Hi, newbie here.
I switched from ntpsec to chrony (debian12). Same upstream servers. The score was 20, now it is 17.4. About 10 hours since the switch.
Is this normal, will it staibilize? Maybe any mistake in chrony config?
Thanks 
(this post was flagged/hidden by community, why?)
hi magnemann, welcome to the NTPpool community board.
Although I’m not familiar with the settings and behavior of chrony, the screenshot does not look good. I doubt that scores will still converge.
Could you please runthe following command on chrony:
chronyc tracking. Maybe this will tell us a little more about what’s going on.
Hi magnemann,
some more ideas how you can troubleshoot this:
journalctl -eu chrony and look if there are any error messages loggedchronyc sources and chronyc sourcestats to check that chrony receives and correctly interpretes the upstream timeThanks Kets and Sebhoster!
Heres more info.
The ‘ok’ ntpsec server was a LXC server in proxmox.
The 'bad ’ chrony server is a clone of the LXC. (removed ntpsec, installed chrony, installed netdata.)
root@chrony ~# chronyc tracking
Reference ID : C23ACA94 (sth2.ntp.netnod.se)
Stratum : 2
Ref time (UTC) : Fri Mar 29 10:52:02 2024
System time : 0.000001080 seconds slow of NTP time
Last offset : +0.078537531 seconds
RMS offset : 0.066792563 seconds
Frequency : 3751.867 ppm slow
Residual freq : -97.271 ppm
Skew : 328.474 ppm
Root delay : 0.013544550 seconds
Root dispersion : 0.067402497 seconds
Update interval : 6.4 seconds
Leap status : Normal
root@chrony ~# chronyc sources
^x ntp1.belbone.be 2 6 377 28 +92ms[ +92ms] +/- 19ms
^+ nux.hackeriet.no 2 6 377 36 +61ms[ +78ms] +/- 4871us
^- ntp1.hjelmenterprises.com 2 6 377 48 +20ms[ +105ms] +/- 53ms
^x tnnss.net 2 6 377 47 +19ms[ +104ms] +/- 4010us
^- ntp-public.uit.no 1 6 377 34 +68ms[ +68ms] +/- 15ms
^* sth2.ntp.netnod.se 1 6 377 42 +39ms[ +55ms] +/- 6465us
^- 195.64.118.26 2 6 377 50 +13ms[ +97ms] +/- 31ms
root@chrony ~# journalctl -eu chrony
Mar 29 11:27:09 chrony chronyd[1743]: Selected source 195.13.23.5
Mar 29 11:27:29 chrony chronyd[1743]: Selected source 185.35.202.197 (nux.hackeriet.no)
Mar 29 11:29:19 chrony chronyd[1743]: Selected source 185.175.56.95 (tnnss.net)
Mar 29 11:30:23 chrony chronyd[1743]: Selected source 195.13.23.5
Mar 29 11:31:34 chrony chronyd[1743]: Selected source 185.35.202.197 (nux.hackeriet.no)
Mar 29 11:32:38 chrony chronyd[1743]: Can't synchronise: no majority
Mar 29 11:32:40 chrony chronyd[1743]: Selected source 185.35.202.197 (nux.hackeriet.no)
Mar 29 11:33:38 chrony chronyd[1743]: Selected source 185.175.56.95 (tnnss.net)
Mar 29 11:33:44 chrony chronyd[1743]: Selected source 185.35.202.197 (nux.hackeriet.no)
Mar 29 11:34:43 chrony chronyd[1743]: Selected source 185.175.56.95 (tnnss.net)
Mar 29 11:36:52 chrony chronyd[1743]: Selected source 195.13.23.5
Mar 29 11:38:04 chrony chronyd[1743]: Selected source 194.58.202.148 (ntp2.sth.netnod.se)
Mar 29 11:39:01 chrony chronyd[1743]: Selected source 185.175.56.95 (tnnss.net)
Mar 29 11:41:10 chrony chronyd[1743]: Selected source 195.13.23.5
Mar 29 11:41:16 chrony chronyd[1743]: Can't synchronise: no majority
Mar 29 11:41:18 chrony chronyd[1743]: Selected source 185.35.202.197 (nux.hackeriet.no)
Mar 29 11:42:14 chrony chronyd[1743]: Selected source 185.175.56.95 (tnnss.net)
Mar 29 11:42:22 chrony chronyd[1743]: Selected source 185.35.202.197 (nux.hackeriet.no)
Mar 29 11:43:19 chrony chronyd[1743]: Selected source 185.175.56.95 (tnnss.net)
Mar 29 11:43:27 chrony chronyd[1743]: Selected source 185.35.202.197 (nux.hackeriet.no)
Mar 29 11:44:31 chrony chronyd[1743]: Can't synchronise: no majority
Mar 29 11:44:31 chrony chronyd[1743]: Selected source 185.35.202.197 (nux.hackeriet.no)
Mar 29 11:45:35 chrony chronyd[1743]: Selected source 195.64.118.26
Mar 29 11:46:30 chrony chronyd[1743]: Selected source 129.242.4.241 (time.service.uit.no)
Mar 29 11:46:34 chrony chronyd[1743]: Selected source 185.175.56.95 (tnnss.net)
Mar 29 11:46:40 chrony chronyd[1743]: Selected source 185.35.202.197 (nux.hackeriet.no)
Mar 29 11:47:38 chrony chronyd[1743]: Selected source 185.175.56.95 (tnnss.net)
Mar 29 11:47:44 chrony chronyd[1743]: Selected source 194.58.202.148 (ntp2.sth.netnod.se)
Mar 29 11:48:42 chrony chronyd[1743]: Selected source 185.175.56.95 (tnnss.net)
Mar 29 11:48:50 chrony chronyd[1743]: Selected source 185.35.202.197 (nux.hackeriet.no)
Mar 29 11:49:46 chrony chronyd[1743]: Selected source 185.175.56.95 (tnnss.net)
Mar 29 11:49:55 chrony chronyd[1743]: Selected source 185.35.202.197 (nux.hackeriet.no)
Mar 29 11:50:57 chrony chronyd[1743]: Can't synchronise: no majority
Mar 29 11:51:00 chrony chronyd[1743]: Selected source 194.58.202.148 (ntp2.sth.netnod.se)
Mar 29 11:51:56 chrony chronyd[1743]: Selected source 185.175.56.95 (tnnss.net)
Mar 29 11:52:02 chrony chronyd[1743]: Selected source 194.58.202.148 (ntp2.sth.netnod.se)
Mar 29 11:53:00 chrony chronyd[1743]: Selected source 185.175.56.95 (tnnss.net)
Mar 29 11:53:07 chrony chronyd[1743]: Selected source 194.58.202.148 (ntp2.sth.netnod.se)
Mar 29 11:54:05 chrony chronyd[1743]: Selected source 185.175.56.95 (tnnss.net)
Mar 29 11:54:16 chrony chronyd[1743]: Selected source 194.58.202.148 (ntp2.sth.netnod.se)
Mar 29 11:55:09 chrony chronyd[1743]: Selected source 185.175.56.95 (tnnss.net)
Mar 29 11:55:23 chrony chronyd[1743]: Selected source 129.242.4.241 (time.service.uit.no)
root@chrony ~ [127]# chronyc sourcestats
ntp1.belbone.be 7 3 388 +552.867 2445.381 -148ms 115ms
nux.hackeriet.no 6 3 325 +1215.991 3932.526 -63ms 107ms
ntp1.hjelmenterprises.com 6 5 325 +1926.641 3362.056 +53ms 103ms
tnnss.net 6 3 323 +1562.413 3261.643 +787us 108ms
ntp-public.uit.no 6 3 324 +1201.509 2636.864 +5956us 99ms
sth2.ntp.netnod.se 6 3 322 +991.368 3321.663 -120ms 96ms
195.64.118.26 6 3 322 +1778.135 2976.997 +52ms 94ms
config:
confdir /etc/chrony/conf.d
cmdallow 10.0.0.0/20
bindcmdaddress 0.0.0.0
bindcmdaddress ::
allow all
server 195.13.23.5 iburst
server nux.hackeriet.no iburst
server ntp.hjelmenterprises.com iburst
server tnnss.net iburst
server time.service.uit.no iburst
server ntp2.sth.netnod.se iburst
server 195.64.118.26 iburst
keyfile /etc/chrony/chrony.keys
driftfile /var/lib/chrony/chrony.drift
ntsdumpdir /var/lib/chrony
logdir /var/log/chrony
maxupdateskew 100.0
rtcsync
makestep 1 3
leapsectz right/UTC
Has anything else changed? Server’s bandwidth setting in the pool portal? Network configuration/connectivity? Higher load on the Internet link or a gateway/firewall in front of the system? Load on the platform where the container is running?
That looks like there are two things trying to control the system clock at the same time, fighting with each other. Is there any other NTP client running, e.g. the default one of proxmox?
Thanks, good suggestions.
I dont think anything has changed.
As I said, I cloned the ‘ok’ LXC container running ntpsec, installing chrony on the clone. Also I changed the private IP.
Thanks, you might be into something.
The physical host running proxmox is also running chrony. And it has ‘rtcsync’ in config.
Could it be that both host and LXC is setting the hardware clock, making a mess?
EDIT: I disabled chrony on the host. Heres the LIVE results: pool.ntp.org: magnemann's pool servers
Lets wait some time to see if something changes.
I would remove that line. Never seen anybody use it.
Also it looks to me your system-clock is way off, do it doesn’t know what clock to believe to be correct.
If you know one of them if correct and never fails, then you may want to give it the TRUST of PREFER status, so chrony knows it should be the correct one.
Typical a stratum 1 server should be used for TRUST, as it’s synched with a STRATUM 0 provider via an (in)direct link like a GPS.
I know of these to be always correct as they are Belgian Astronomy timeservers:
server ntp-main-1.oma.be trust
server ntp-main-2.oma.be trust
Now let it run a bit, see what Chrony does.
I use it. 
There hasn’t been another leap second yet, though! (And, of course, there may not be.)
You are the only one it seems.
However, you should install the 2 trusted servers I gave you, so Chrony can work out the correct time.
It should normalize after 30 minutes or so.
Then run ‘chronyc makestep’ a few times, like every 5 minutes, and it will bring the sysemtime to the real time. And chrony will know what the real time is.
Then the monitors will normalize too. If not, you have other problems.
Hardware clock as in RTC is not usually used while the system is running, only read upon system startup to get initial time, then set periodically to stay in sync while the system is running, but not usually read anymore.
Rather, containers (unlike VMs) run on the kernel of the host system, so I guess both chronyd inside as well as the one outside the container trying to manage time on the same kernel sounds like asking for trouble 
Looking much better now… 
Allright, its looking better now after I disabled chrony on proxmox host.
I think the reason for the trouble was LXC and proxmox host both set the system time, both running chrony.
Trying to wrap my head about this, good to have some trouble to learn a bit.
Have I understand the following?
‘hardware clock’ is always used to set system time at boot, may be set later also by e.g. chrony. This clock is not used actively by chrony.
‘system time’ is used for everything in linux, e.g. ‘date’ command and the journal. System time is set often/10min by chrony.
‘true time’ (is this the right term?) is the true time for the world. Estimated by chrony. When true time is copied to system time, the system is ‘synchronized’.
Are there more ‘times’?
So… Does proxmox host and LXC have common system time (they share kernel)? Is it best practice to disable ntp client on the host, if running a time server on LXC?
Awesome support, thanks.
Thanks, interesting info!
Im sure these are accurate servers. But I dont know anything about the latency from Norway to Belgium. Also I believe one should not trust anything in this protocol.
How do I find the ‘best’ servers? Should I choose stratum 1 or 2? What happens If I choose some stratum 1 and some stratum 2 as upstream servers, what will my own stratum be?
if you’re locked to a stratum 2 server, you’d be stratum 3 (2+1). But I think there’s preference for the stratum 1 server, so probably stratum 2 (1+1).
You do not need to know latency or other…as it’s compensated.
You only need to know they are ticking correctly.
As Norway is close to Belgium, you can assume they tick corect.
They are Stratum 1, both…and I know for sure they are good.
I do not even trust my own Stratum 1 servers that much, and I’m pretty close 
From this day, this is my new motto.
Can we trust stratum 0? I must find some reading on this.
Anyway, latency matters much. High latency gives more chance for asychron rund-trip for the udp packets, giving larger error.
Also im looking for cheap way to test stratum 1.
I see you use one of my servers, tnnss.net, as a source. Like most of the servers in Norway, it uses ntp.justervesenet.no as its primary source, which is run by the Norwegian Metrology Service. Another service you can trust is Swedish Netnod, who also supports NTS.
The roundtrip time should be great with these, and I’m seeing a ping time within the millisecond (0.9ms) to Justervesenet’s server and a steady 7.6ms to Netnod.
The graphs from this look cool at least.
The cheapest way is to get an GPS, either module USB+PPS, Garmin 18X (requires 5 wires to solder) or an U-blox module but requires soldering and electronic knowledge.
The USB module that has PPS, in ready made form costs about 80 euro.
The Garmin is about 100 euro including shipping, my favorite (some disagree )
The U-blox modules are very cheap, but you need converters and electronic skills, the module itself is about 10~20 euro.
If you do not care about PPS, then an USB module could be found for 10~15 euro, but it’s not precise enough, but could help setting the right time.
The most easy one to use and install is this one:
Navisys GR-701W u-blox-7 USB PPS GPS/qzss & GLONASS ontvanger
All via USB, just plug it in an USB port and off you go