Score dropped when switching to chrony

[Bas]

@ask

The graphs from this look cool at least.

Another thing, it shows also that using multiple monitor system we have now works!!!
And works well.

As this is/was a sample of a wrong ticker and it was noticed right away and did show how ‘bad’ this server is/was.

With the old system it would give timeouts and not show enough information.

As such @ask you can pat yourself on the back, as you have done a great job programming this great new monitorring system.

WELL DONE!!!

We solved the first real problem right away thanks to your work, without much troubles.

[paulgear]

@magnemann

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’?

I think you’ve got most of the basics right there. You might find some posts I recently published to be helpful - series starts here: What’s the time, Mister Cloud? An introduction to and experimental comparison of time synchronisation in AWS and Azure It goes into the fundamentals of timekeeping on bare metal, virtual machines, and containers.

@magnemann

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?

LXC is actually capable of managing both VMs and containers, so it depends on what you’ve selected as to what the correct answer is here, but the most important thing is: no, it’s not best practice to disable NTP on the host. It’s best practice to make the host as accurate as possible. If you’re running chrony in a container, it can’t control the system clock unless you’ve given it explicit permissions to do so. Better to have the host do the time sync and the container just be used for serving that time to the pool.

[Bas]

@magnemann

@paulgear

If you’re running chrony in a container, it can’t control the system clock unless you’ve given it explicit permissions to do so. Better to have the host do the time sync and the container just be used for serving that time to the pool.

In fact, Chrony doesn’t need the systemclock at all.
It can work out the correct time after a few minutes by comparing other servers.

But if you have a connection or container with a lot of jitter or CPU-speed changes, it can not work out the exact time. As such it doesn’t know what source to trust/select.

As you have seen in the logs, where it can’t decide.

When running Chrony in a container, give this in /etc/default/chrony:

DAEMON_OPTS="-F 1 -x"

Then it won’t use the systemclock (if absent) or tries to regulate it.

Let the container-chrony run on it’s own, it will work out the correct time and serve as such.

Chrony doesn’t need the RTC to function, it will work perfectly without.

This is mine in a container, using those parameters and serving the right time:

root@stun:~# chronyc tracking
Reference ID    : 4D6D5A48 (heppen.be)
Stratum         : 2
Ref time (UTC)  : Sun Mar 31 14:07:11 2024
System time     : 0.001944188 seconds fast of NTP time
Last offset     : +0.000042983 seconds
RMS offset      : 0.000043745 seconds
Frequency       : 0.626 ppm fast
Residual freq   : +0.010 ppm
Skew            : 0.841 ppm
Root delay      : 0.019564660 seconds
Root dispersion : 0.000426578 seconds
Update interval : 16.0 seconds
Leap status     : Normal

As you can see the system-time isn’t very accurate, yet Chrony knows what it should be and serves perfectly.

[magnemann]

Thanks, this is incredibly useful info!

[magnemann]

Thanks for the info and for the posts!
I enabled chrony again on the proxmox host. On the LXC running chrony server, Im using the -x parameter, so its not touching the system clock. I agree this makes most sense.

[Bas]

@magnemann

Im using the -x parameter, so its not touching the system clock. I agree this makes most sense.

Also, mark trusted good servers as trusted or preferred, like I explained before.
Then it will work fine.

[paulgear]

@Bas

Also, mark trusted good servers as trusted or preferred, like I explained before.
Then it will work fine.

That is bad advice. What if those “good” servers become “not good”? You need to give the NTP service the option to switch away from it if its time quality decreases.

Good advice would be: configure additional remote sources which can be used to improve the calculations and fill in for your usual stratum 1 if necessary. If your usual source is really “good”, then it will be selected as the sync peer anyway.

[paulgear]

@Bas

In fact, Chrony doesn’t need the systemclock at all.

That is factually incorrect. It doesn’t need to write the system clock. It (and virtually every other process) absolutely needs to be able to read the system clock. Otherwise, it wouldn’t know the time on the local system and would have no way of determining how fast or slow of UTC it is.

[Bas]

@paulgear, true, but I meant the RTC-clock. Sorry.
Many systems don’t have this, like the RaspberryPi or a container.

If you read the entire topic, Chrony wasn’t able to workout the right time with multiple sources. As such I suggested trust or prefer as option.

Also, if such a ticker goes wrong, with prefer it will switch.
And if your system has the wrong time, the pool will email you to alert you.

We did also suggest he uses his own stratum-1 device