Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Computer not keeping time, NTP not helping
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
mr-simon
Guru
Guru


Joined: 22 Nov 2002
Posts: 362
Location: Leamington Spa, Warks, UK

PostPosted: Sun Sep 03, 2017 12:27 pm    Post subject: Computer not keeping time, NTP not helping Reply with quote

My Gentoo installation isn't keeping time. It's quite slow, and will drift ~8 hours in the space of a few days. My Windows install on the same PC keeps time OK.

I've overclocked the PC both by changing the CPU multiplier and base frequency (101 instead of 100) which might explain the issue, although I've overclocked Gentoo PCs before and not had this issue.

Running `rdate -s ntp.demon.co.uk` sets the time just fine, but I'm running net-misc/openntpd (I've tried plain-old ntpd as well) and it's not keeping the time up-to-date. I'm not sure how to diagnose this. `ntpctl -s status` tells me that my clock is unsynced. After I run rdate to set the time, it becomes synced temporarily, but then becomes unsynced again very quicky:

Code:
simon@firebrand:13:23:42 ruby-2.4.0 [~/junk]
-> sudo ntpctl -s status
8/20 peers valid, clock synced, stratum 3

simon@firebrand:13:23:43 ruby-2.4.0 [~/junk]
-> sudo ntpctl -s status
10/20 peers valid, clock unsynced, clock offset is 3059.585ms


Two questions:
- How do I find out why my clock is drifting, and can I do anything to fix it?
- Why isn't NTP keeping my clock in time.
_________________
"Pokey, are you drunk on love?"
"Yes. Also whiskey. But mostly love... and whiskey."
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 7161
Location: almost Mile High in the USA

PostPosted: Sun Sep 03, 2017 1:36 pm    Post subject: Reply with quote

They may be of the same problem.

Curious if you have other linux machines of the same caliber or use the same programs in Windows and whether they feel slow?

Code:
$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
kvm-clock
$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
kvm-clock hpet acpi_pm


(Ignore kvm-clock. I ran these on a virtual machine, and unless you're also running on a VM, you won't ever see this option.)
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed watching?
Back to top
View user's profile Send private message
mr-simon
Guru
Guru


Joined: 22 Nov 2002
Posts: 362
Location: Leamington Spa, Warks, UK

PostPosted: Sun Sep 03, 2017 3:02 pm    Post subject: Reply with quote

Nothing feels slow, it's a very fast machine. ;-) It's just the sysclock that's running slow.
Code:
simon@firebrand:15:53:49 ruby-2.4.0 [~/junk]
->  cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc

simon@firebrand:15:53:51 ruby-2.4.0 [~/junk]
->  cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm

... is what I see, but I don't know what it means.

I don't have the same programs on my Windows install (I only use it for audio production), or a similarly-specced computer somewhere else.
_________________
"Pokey, are you drunk on love?"
"Yes. Also whiskey. But mostly love... and whiskey."
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 7161
Location: almost Mile High in the USA

PostPosted: Sun Sep 03, 2017 3:33 pm    Post subject: Reply with quote

I'm sort of basing this off the slow clock on my tablet when I was using it. It was running much slower than what it should be running at, for anything depending on real time like GUI animations and click timeouts. Turns out it was using HPET and the HPET was broken on that particular machine, which shows up as its clock was ticking 1 second for every 4 or so seconds real time. Using other timesources were a bit better, but it still lost time...

Usually this is a hardware problem, you could try using a different clocksource like HPET, it might work better due to hardware problems working with TSC (TSC is usually the most accurate).

# echo hpet > /sys/devices/system/clocksource/clocksource0/current_clocksource

It should give you warnings in dmesg if there's problems with TSC, however. Still a mystery...
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed watching?
Back to top
View user's profile Send private message
mr-simon
Guru
Guru


Joined: 22 Nov 2002
Posts: 362
Location: Leamington Spa, Warks, UK

PostPosted: Sun Sep 03, 2017 8:52 pm    Post subject: Reply with quote

Thanks for yourself so far. :) -- Here's something interesting:
Code:
simon@firebrand:21:28:10 ruby-2.4.0 [~/junk]
-> dmesg | grep -i tsc
[    0.010000] tsc: Detected 3300.000 MHz processor
[    0.010000] [Firmware Bug]: TSC ADJUST: CPU0: -39232680888818 force to 0
[    0.162625] TSC deadline timer enabled
[    0.010000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -39232680888818 CPU1: 0
[    0.010000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -39232680888818 CPU2: 0
[    0.010000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -39232680888818 CPU3: 0
[    0.010000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -39232680888818 CPU4: 0
[    0.010000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -39232680888818 CPU5: 0
[    0.010000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -39232680888818 CPU6: 0
[    0.010000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -39232680888818 CPU7: 0
[    0.010000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -39232680888818 CPU8: 0
[    0.010000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -39232680888818 CPU9: 0
[    0.010000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -39232680888818 CPU10: 0
[    0.010000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -39232680888818 CPU11: 0
[    0.010000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -39232680888818 CPU12: 0
[    0.010000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -39232680888818 CPU13: 0
[    0.010000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -39232680888818 CPU14: 0
[    0.010000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -39232680888818 CPU15: 0
[    0.010000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -39232680888818 CPU16: 0
[    0.010000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -39232680888818 CPU17: 0
[    0.010000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -39232680888818 CPU18: 0
[    0.010000] [Firmware Bug]: TSC ADJUST differs: Reference CPU0: -39232680888818 CPU19: 0
[    3.830295] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x31bad01a63d, max_idle_ns: 440795332416 ns
[    4.801924] clocksource: Switched to clocksource tsc
[   30.181118] vboxdrv: TSC mode is Invariant, tentative frequency 3450000126 Hz

That looks from that like tsc might be an issue, BUT switching to hpet doesn't help. It's still drifting as before.

The tsc-related flags from my /proc/cpuinfo are: tsc rdtscp (unrelated?) constant_tsc nonstop_tsc tsc_known_freq tsc_deadline_timer tsc_adjust - I'm not sure if any of that is useful information.

Whilst writing this reply I have set the clock source to hpet, resynced the time, and it has now drifted (according to ntpctl) by ~720ms.

I'm not sure why ntp isn't keeping my clock in sync? Maybe it's not quite designed for this use case though...

Here's everything else dmesg says about clock:
Code:
simon@firebrand:21:40:27 ruby-2.4.0 [~/junk]
-> dmesg | fgrep -i clock
[    0.000000] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.000000] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635855245 ns
[    0.000000] hpet clockevent registered
[    3.020112] sched_clock: Marking stable (3020000000, 0)->(3063271071, -43271071)
[    3.021862] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    3.062107] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
[    3.069297] acpi PNP0A08:01: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
[    3.100220] acpi PNP0A08:02: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
[    3.130224] acpi PNP0A08:03: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
[    3.133741] PTP clock support registered
[    3.140254] clocksource: Switched to clocksource hpet
[    3.157240] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns
[    3.830295] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x31bad01a63d, max_idle_ns: 440795332416 ns
[    4.020894] rtc_cmos 00:00: setting system clock to 2017-08-30 11:22:20 UTC (1504092140)
[    4.801924] clocksource: Switched to clocksource tsc
[   30.576551] e1000e 0000:00:1f.6 0000:00:1f.6 (uninitialized): registered PHC clock
[363211.330028] clocksource: Switched to clocksource hpet

Does any of this help?

I've just tried setting the clocksource to acpi_pm, and it appears to also be showing the problem, so looks like all clocksources have the same problem.
_________________
"Pokey, are you drunk on love?"
"Yes. Also whiskey. But mostly love... and whiskey."
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 7161
Location: almost Mile High in the USA

PostPosted: Sun Sep 03, 2017 9:05 pm    Post subject: Reply with quote

Hmm. Odd. What happens if you disable HPET in your kernel, it should then allow you to use the even less accurate PIT but it uses a different clock source.

Do you have the RTC code compiled in your kernel? Is your RTC time accurate? Perhaps you could cron rereading the RTC every so often as a workaround? hwclock --hctosys

I suspect NTP doesn't know how to handle clocks that drift over a certain percentage; it tries to correct for it but when the error is large it gives up.
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed watching?
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum