0

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.

Philipp Burch
  • 869
  • 1
  • 7
  • 16

1 Answers1

0

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.

Philipp Burch
  • 869
  • 1
  • 7
  • 16