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