LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Kernel (https://www.linuxquestions.org/questions/linux-kernel-70/)
-   -   system clock runs faster in 64-bit kernel (https://www.linuxquestions.org/questions/linux-kernel-70/system-clock-runs-faster-in-64-bit-kernel-4175665293/)

h1uke 12-02-2019 11:07 AM

system clock runs faster in 64-bit kernel
 
Recently we upgraded our legacy device to a newer, 64-bit kernel (4.1.3 --> 5.0.12) and found that the TSC-based system clock runs faster under a 64-bit OS.
It is an embedded Intel Atom box(4 x E3800), no external NTP service available.
The 64-bit OS system clock is gaining approximately 2 seconds per hour compared to a 32-bit one, which is not acceptable.

Different TSC calibration methods used in two different kernels, and the results are also different (see below).

Does this look familiar to anyone? Just wanted to ask before diving into the source code.

Thanks.

Code:

---- dmesg | grep -i TSC ----------

64-bit kernel 5.0.12 :

[    0.000000] tsc: Detected 1915.900 MHz processor
[    0.150872] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x373bb0d4809, max_idle_ns: 881590714052 ns
[    0.156020] TSC deadline timer enabled
[    0.677033] clocksource: Switched to clocksource tsc-early
[    2.249153] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x373bb0d4809, max_idle_ns: 881590714052 ns
[    2.249187] clocksource: Switched to clocksource tsc
---------------------------------

32-bit kernel 4.1.3 :

TSC runs at 1913600 KHz
tsc: Detected 1913.600 MHz processor
TSC deadline timer enabled
tsc: Refined TSC clocksource calibration: 1916.670 MHz
clocksource tsc: mask: 0xffffffffffffffff max_cycles: 0x37415f43c80, max_idle_ns: 881590514357 ns
---------------------------------


rigor 12-07-2019 01:05 AM

hi h1uke!


I'm certainly not sure, but just a couple thoughts offhand.

1) I thought there is a 3820 CPU that is 64-bit, don't know about the 3800.
2) Although there appear to be identical "mask" values shown, I do have to wonder if the 64-bit OS is expecting a 64-bit CPU and so is doing calculations with, in some sense, 64-bit accuracy, while the 32-bit OS is expecting 32-bit accuracy. I wonder if that results in the slight difference in the other values.

h1uke 12-16-2019 06:56 AM

here's the update:

- there's nothing to do with the 64-bit vs the 32-bit kernel. The real cause for a problem is a [surprisingly] different implementation of "arch/x86/kernel/tsc.c" in 5.0.12 vs 4.1.3 kernel source tree as it found on kernel.org.

- the TSC frequencies calculated by two implementations above are slightly different: 1916.670 MHz in v4.1.3 vs 1915.9 MHz in v5.0.12 _on_the_same_box_. Simply calculations show that this will cause the system clock in v5.0.12 to run faster gaining ~ 400usec every second, which results in approximately 33 minutes per day.

- we were able to confirm the above numbers by measuring/averaging the number of microsecond cycles ( using gettimeofday() ) between two consecutive 1-second pulses of the onboard DS3231 RTC chip -- our system clock advances by ~ 100385 microseconds per second tick provided by an independent chip which is very accurate

- a quick and dirty workaround is used for now: we extended the system startup script with a call to adjtimex which modifies the kernel time constants according to our needs.
A convenient calculator of adjtimex parameters can be found here

P.S. rigor: besides this is irrelevant ... the CPU we use is Intel Atom E3845, which contains four cores belonging to E3800 family

ordealbyfire83 01-11-2020 09:56 AM

As a workaround, can you change the clock source? I think something like "cat /sys/devices/system/clocksource/clocksource0/available_clocksource" should show what other clock sources can be used. You can change it at boot time using the clocksource= kernel parameter or echo that to the current_clocksource entry in the same directory.


All times are GMT -5. The time now is 12:29 AM.