Bug 716310

Summary: ntpd does not work
Product: [Fedora] Fedora Reporter: John Mev <zikamev>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED WORKSFORME QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 15CC: gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, mlichvar, pertusus, zikamev
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-09-27 16:11:25 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
result of "dmesg" none

Description John Mev 2011-06-23 22:12:51 UTC
Description of problem:

ntpd does not work
my system : MB Gigabyte + Core i7 920 + 6 GB ram

uname -r 2.6.38.8-32.fc15.i686.PAE

Version-Release number of selected component (if applicable):

ntp-4.2.6p3-4.fc15.i686

How reproducible:

When I start the machine, I have:

systemctl status ntpd.service 
ntpd.service - Network Time Service
	  Loaded: loaded (/lib/systemd/system/ntpd.service)
	  Active: active (running) since Thu, 23 Jun 2011 18:11:25 +0200; 5h 32min ago
	Main PID: 911 (ntpd)
	  CGroup: name=systemd:/system/ntpd.service
		  └ 911 /usr/sbin/ntpd -n -u ntp:ntp -g



5 hours later, the time is wrong, so I do:
systemctl stop ntpd.service
systemctl start ntpdate.service

to set the good time.

and a "grep ntpd  /var/log/messages" shows:

ntpdate[31156]: step time server 145.238.203.10 offset 809.777667 sec

i.e in 5 hours the system is 12 mn late !!

Comment 1 Miroslav Lichvar 2011-06-24 07:53:28 UTC
Such large drift is usually a hw or kernel problem.

ntp can adjust the clock rate at most by ~2 seconds per hour, in your case it would need to make 80 times larger adjustment!

You may have better luck with chrony, it can adjust the clock rate up to 10%, but it's really the underlying hw/kernel issue that needs to be fixed here.

Comment 2 John Mev 2011-06-24 09:27:58 UTC
Thx I'll try it and report the result.

Comment 3 Chuck Ebbert 2011-06-25 07:15:04 UTC
What clocksource is it using?

I have:
# grep "" /sys/devices/system/clocksource/clocksource0/*
/sys/devices/system/clocksource/clocksource0/available_clocksource:tsc hpet acpi_pm 
/sys/devices/system/clocksource/clocksource0/current_clocksource:tsc

Also please attach the output of the "dmesg" command (as a plaintext attachment.)

Comment 4 John Mev 2011-06-25 16:14:13 UTC
Created attachment 509902 [details]
result of "dmesg"

Here is the file dmesg requested.

Comment 5 John Mev 2011-06-25 16:15:46 UTC
(In reply to comment #3)
> What clocksource is it using?
> 
> I have:
> # grep "" /sys/devices/system/clocksource/clocksource0/*
> /sys/devices/system/clocksource/clocksource0/available_clocksource:tsc hpet
> acpi_pm 
> /sys/devices/system/clocksource/clocksource0/current_clocksource:tsc
> 
> Also please attach the output of the "dmesg" command (as a plaintext
> attachment.)

I have the same:

root # grep "" /sys/devices/system/clocksource/clocksource0/*
/sys/devices/system/clocksource/clocksource0/available_clocksource:tsc hpet acpi_pm 
/sys/devices/system/clocksource/clocksource0/current_clocksource:tsc

And finally, I have already submitted this bug on Fedora 12, with the same hw.

Comment 6 Chuck Ebbert 2011-06-27 05:14:28 UTC
And does booting with "clocksource=hpet" fix the timekeeping?

Comment 7 John Mev 2011-06-27 09:35:29 UTC
Is this a command that I must enter on the kernel line of grub.conf ?

For the test, I'll try, but for this test I must wait a while, because I switched to chrony as said in comment #1

Comment 8 Miroslav Lichvar 2011-06-27 09:59:00 UTC
Yes, it's the kernel line in grub.conf.

You can also switch it temporarily (until next boot) by
echo hpet > /sys/devices/system/clocksource/clocksource0/current_clocksource

What's the output of "chronyc tracking"? When the frequency value is below 500 ppm and the skew is small enough (say below 50 ppm), ntpd should work too.

Comment 9 John Mev 2011-06-28 09:11:31 UTC
Hi

here is the output :

/root # chronyc tracking
Reference ID    : 145.238.203.10 (syrte8.obspm.fr)
Stratum         : 3
Ref time (UTC)  : Tue Jun 28 09:06:48 2011
System time     : 0.000000 seconds fast of NTP time
Frequency       : 32768.000 ppm slow
Residual freq   : 4.718 ppm
Skew            : 261.840 ppm
Root delay      : 0.021332 seconds
Root dispersion : 0.038422 seconds

So, ntp worked sometimes and sometimes not, its was as a lottery and I'm glad to have chrony working fine!

But however I shall try soon the command you gave me with ntpd

Comment 10 John Mev 2011-07-27 12:05:20 UTC

"(In reply to comment #6)
> And does booting with "clocksource=hpet" fix the timekeeping?

Finally I can confirm that this option in the kernel line resolves the issue.

Thx a lot !