[SOLVED] system time lags behind hardware time

solarfields · 01-24-2018, 11:21 AM

hi to all,

i am in a bit of a puzzling situation here. I am running -current and the system time lags with 2 sec per minute behind the hardware clock. The hardware clock is correct.

Any ideas how to fix this?

keefaz · 01-24-2018, 11:30 AM

Pick a time server here: http://www.pool.ntp.org
Then

Code:

ntpdate <time server>
hwclock --systohc
# or use utc if hardware clock set to utc
hwclock --utc --systohc

PROBLEMCHYLD · 01-24-2018, 12:08 PM

This work as well if you travel much.

https://www.linuxquestions.org/quest...4/#post5678525

orbea · 01-24-2018, 12:11 PM

One more relevant article.

https://docs.slackware.com/howtos:network_services:ntp

solarfields · 01-24-2018, 12:12 PM

thanks for the hints guys, but i am not looking for a workaround.

IMHO, losing 2 seconds per minute hints of an issue with the system itself.

Darth Vader · 01-24-2018, 12:33 PM

I have two computers which behave this way, both being Phenom x4 on AM2+ socket over RS780 chipsets.

The cause (identified by me) was an unreliable TSC clocksource, and switching to HPET one fixed the issue.

solarfields · 01-24-2018, 12:59 PM

well, i have never encountered such behaviour. Also, the computer could not synchronise its time by ntp. Maybe 2 sec per minute is too much.

Darth Vader · 01-24-2018, 01:07 PM

I suggest you to try another clocksource.

Basically, it is about adding in the kernel command line something like

Code:

notsc clocksource=hpet

before, you should inspect for the available options

Code:

# the available clocksources
/sys/devices/system/clocksource/clocksource0/available_clocksource

# this one will tell which clocksource you use currently (probably TSC)
/sys/devices/system/clocksource/clocksource0/current_clocksource

Be warned that anything else than TSC or HPET probably would affect seriously the responsiveness of your system.

solarfields · 01-25-2018, 03:33 AM

i upgraded the kernel to 4.15-rc9 and so far, it seems to fix the issue. Maybe this has something to do with it?

https://git.kernel.org/pub/scm/linux...&id2=v4.15-rc8

I am marking the thread as SOLVED, but will reopen it if any new problems arise...

orbea · 01-25-2018, 06:30 AM

Quote:

Originally Posted by solarfields

thanks for the hints guys, but i am not looking for a workaround.

IMHO, losing 2 seconds per minute hints of an issue with the system itself.

The issue with the system is that you didn't configure ntp...

bassmadrigal · 01-25-2018, 06:52 AM

Quote:

Originally Posted by orbea

The issue with the system is that you didn't configure ntp...

Being off by 2 seconds every minute is not a lack of configuring ntp. Small drifts are to be expected, but 2 minutes every hour means there is some other issue causing that much drift. Sure, ntp can correct it whenever it syncs with the server, but it's just covering up the problem...

orbea · 01-25-2018, 07:09 AM

I think its still probably the best solution. I suspect other solutions would just be ignoring the elephant in the room, that older methods can be unreliable. There is a reason most if not all help on this subject is related to configuring ntp, so unless you have another solution you'd like to propose I'd appreciate it if you didn't mislead the op.

Quote:

The Time Stamp Counter was once an excellent high-resolution, low-overhead way for a program to get CPU timing information. With the advent of multi-core/hyper-threaded CPUs, systems with multiple CPUs, and hibernating operating systems, the TSC cannot be relied upon to provide accurate results — unless great care is taken to correct the possible flaws: rate of tick and whether all cores (processors) have identical values in their time-keeping registers. There is no promise that the timestamp counters of multiple CPUs on a single motherboard will be synchronized. Therefore, a program can get reliable results only by limiting itself to run on one specific CPU. Even then, the CPU speed may change because of power-saving measures taken by the OS or BIOS, or the system may be hibernated and later resumed, resetting the TSC. In those latter cases, to stay relevant, the program must re-calibrate the counter periodically.

https://en.wikipedia.org/wiki/Time_Stamp_Counter#Use

solarfields · 01-25-2018, 07:24 AM

orbea,

i already posted my solution: upgrading to a newer kernel (4.15.0-rc9) fixed the problem. Lagging 2 seconds every minute seemed to me as an indication that something was wrong with the system itself. I can check how kernel 4.14.15 works and if it is also OK -- will write in the requests for -current.

Also, I set up ntp: it failed to sync my clock. I read somewhere that probably my clock was lagging too fast for it to 'catch up'.

Maybe it was even worse than that, my system was gradually falling some 10-15 min behind in a matter of several hours. I did not have the patience to use my stopwatch for so long...

Petri Kaukasoina · 01-25-2018, 07:39 AM

Quote:

Originally Posted by solarfields

I can check how kernel 4.14.15 works and if it is also OK -- will write in the requests for -current.

This is from ChangeLog-4.14.15. (24 MHz vs 25 MHz means a little more than 2 secs a minute.)

Code:

commit 8352a3fec216b76b645f583f294efc711b3ca1bd
Author: Len Brown <len.brown@intel.com>
Date:   Fri Dec 22 00:27:55 2017 -0500

    x86/tsc: Fix erroneous TSC rate on Skylake Xeon
    
    commit b511203093489eb1829cb4de86e8214752205ac6 upstream.
    
    The INTEL_FAM6_SKYLAKE_X hardcoded crystal_khz value of 25MHZ is
    problematic:
    
     - SKX workstations (with same model # as server variants) use a 24 MHz
       crystal.  This results in a -4.0% time drift rate on SKX workstations.
    
     - SKX servers subject the crystal to an EMI reduction circuit that reduces its
       actual frequency by (approximately) -0.25%.  This results in -1 second per
       10 minute time drift as compared to network time.
    
    This issue can also trigger a timer and power problem, on configurations
    that use the LAPIC timer (versus the TSC deadline timer).  Clock ticks
    scheduled with the LAPIC timer arrive a few usec before the time they are
    expected (according to the slow TSC).  This causes Linux to poll-idle, when
    it should be in an idle power saving state.  The idle and clock code do not
    graciously recover from this error, sometimes resulting in significant
    polling and measurable power impact.
    
    Stop using native_calibrate_tsc() for INTEL_FAM6_SKYLAKE_X.
    native_calibrate_tsc() will return 0, boot will run with tsc_khz = cpu_khz,
    and the TSC refined calibration will update tsc_khz to correct for the
    difference.
    
    [ tglx: Sanitized change log ]
    
    Fixes: 6baf3d61821f ("x86/tsc: Add additional Intel CPU models to the crystal quirk list")
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: peterz@infradead.org
    Cc: Prarit Bhargava <prarit@redhat.com>
    Link: https://lkml.kernel.org/r/ff6dcea166e8ff8f2f6a03c17beab2cb436aa779.1513920414.git.len.brown@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

solarfields · 01-25-2018, 08:19 AM

ok, I compiled 4.14.15 and it seems the time is kept accurate. I will of course be checking this later... Thank you Petri, for the quote. And, for the record, my CPU is:

Intel(R) Xeon(R) W-2135 CPU