I'm facing a very strange behaviour on a mainboard with an Intel i7-9700 processor. The hardware clock (RTC) runs correctly, but the system time / walltime runs approx. 5x too slow:
$ sudo hwclock; sleep 10; sudo hwclock
2020-11-20 09:38:19.667199+00:00
2020-11-20 09:39:07.479683+00:00
The 10s sleep took almost 50s to complete. The system time runs away so fast that just about everything crypto-related fails, e.g. HTTPS connections to download updates. Due to the huge mismatch, I suppose that some frequency information somewhere is completely wrong, but where to look for that?
The installed distribution is Ubuntu 20.04.1 LTS. I didn't explicitly check before, but the problem supposedly only arised recently, due to the certainly obvious symptoms. I'm actually quite surprised that WiFi and OpenVPN still works on that machine. Otherwise I wouldn't have access to it right now, as it is in a remote location.
Any ideas about what to check/fix are highly appreciated.
Thank you and best regards, Philipp
Update: It seems that the wallclock no longer accounts for CPU frequency scaling. When the CPU is idle, the clock ticks slowly; as soon as the CPU has something to do, the clocks runs more or less correctly.
The issue indeed seems to be related to the CPU choice/behaviour, but has not directly to do with frequency scaling. Apparently, there is an incompatibility between the Intel i7-9700 and our mainboard (bcmcom MX370QD). The CPU is a 9th-generation product, has 8 cores and a TDP of 65W. As for the mainboard, the supported CPUs are listed as follows:
Supports 8th Gen LGA1151 Intel® Core-i™, Pentium, and Celeron processors* up to 65W TDP
Supports 9th Gen LGA1151 Intel® Core-i™, Pentium, and Celeron processors* with 6 cores or less & up to 95W TDP
Supports 8 Core 9th Gen LGA 1151 Intel® Core-i™ processors* up to 35W TDP
* Processor IccMax <= 138A.
Checking carefully, this variant is actually not officially supported, due to excessive number of cores for the TDP or excessive TDP for the number of cores. Why these constraints apply, I have no idea. But:
Kind-of-solution: The issue goes away by disabling two CPU cores at boot using the maxcpus=6 kernel argument.
What the root cause of the problem is, I don't know. Maybe someone with a deep understanding of the Linux timekeeping system on x86 hardware has an answer.
Old answer, which has only improved, but not fixed the timing:
Ok, I don't know what the real cause of the problem was, but restoring all BIOS settings to their defaults fixed it. The walltime now runs correctly and allows NTP to sync.