Bug 665497 - RHEL4.8-guest time drifts more than 13 seconds after 12 hours
RHEL4.8-guest time drifts more than 13 seconds after 12 hours
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.8
Unspecified Unspecified
low Severity medium
: ---
: ---
Assigned To: Red Hat Kernel Manager
Red Hat Kernel QE team
:
Depends On:
Blocks: Rhel5KvmTier2
  Show dependency treegraph
 
Reported: 2010-12-23 22:39 EST by Amos Kong
Modified: 2015-05-24 20:06 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-20 11:56:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Amos Kong 2010-12-23 22:39:14 EST
Description of problem:
Boot up a guest and wait for 12 hours, check the timedrift by ntpdate,
I've tested RHEL6.0, RHEL5.6 and RHEL4.8,
the timedrift is about 0.3 second for RHEL6.0 and RHEL5.6, it should be normal.
But the drift of RHEL4.8 is too large, it's more than 13 seconds.

Version-Release number of selected component (if applicable):
host kernel: 2.6.18-236.el5
guest kernel: kernel-2.6.9-94.EL
# rpm -qa |grep kvm
kmod-kvm-debug-83-223.el5
etherboot-zroms-kvm-5.4.4-13.el5
kvm-debuginfo-83-223.el5
etherboot-roms-kvm-5.4.4-13.el5
kvm-tools-83-223.el5
kmod-kvm-83-223.el5
kvm-qemu-img-83-223.el5
kvm-83-223.el5

How reproducible:
always

Steps to Reproduce:
1. boot up a rhel4.8 guest
2. sync the systime with ntp server
# ntpdate $ntp_server_addr
3. wait for 12 hours
4. check the timedrift
# ntpdate -q $ntp_server_addr
  
Actual results:
timedrift is more than 13 seconds

Expected results:
timedrift is less than 0.5 second, not sure ?

Additional info:

1. qemu command line:
# qemu-kvm -name 'vm1' -monitor unix:'/tmp/monitor-humanmonitor1-20101213-111527-JNsP',server,nowait -serial unix:'/tmp/serial-20101213-111527-JNsP',server,nowait -drive file='/home/devel/autotest-akong/client/tests/kvm/images/RHEL-4.8-32-virtio.qcow2',index=0,if=virtio,media=disk,cache=none,boot=on,format=qcow2 -net nic,vlan=0,model=virtio,macaddr='9a:72:41:20:5d:bb' -net tap,vlan=0,ifname='t0-111527-JNsP',script='/home/devel/autotest-akong/client/tests/kvm/scripts/qemu-ifup-switch',downscript='no' -m 4096 -smp 2,cores=1,threads=1,sockets=2 -cpu qemu64,+sse2 -soundhw ac97 -vnc :0 -rtc-td-hack -M rhel5.6.0 -usbdevice tablet -no-kvm-pit-reinjection
Comment 1 Zachary Amsden 2011-01-03 15:44:44 EST
Typical questions:

1) What is clocksource in guest?
2) Is guest 32-bit or 64-bit?
3) Is guest being run with recommended kernel parameters?

64-bit: notsc divider=10
32-bit: clock=pmtmr divider=10
Comment 2 Amos Kong 2011-01-04 04:15:13 EST
(In reply to comment #1)
> Typical questions:
> 
> 1) What is clocksource in guest?

64: pit
32: pmtmr

> 2) Is guest 32-bit or 64-bit?

Both of them

> 3) Is guest being run with recommended kernel parameters?
> 
> 64-bit: notsc divider=10
> 32-bit: clock=pmtmr divider=10

Yes.
Comment 3 Amos Kong 2011-01-05 21:02:26 EST
(In reply to comment #2)
> (In reply to comment #1)
> > Typical questions:
> > 
> > 1) What is clocksource in guest?
> 
> 64: pit
> 32: pmtmr
>
> > 2) Is guest 32-bit or 64-bit?
> 
> Both of them

Hi Zachary,

I and michen retested several times, the timedrift of 64-bit guest is very little (drift about 1 seconds after 10 hours, so we can ignore it).
But the timedrift of 32-bit guest is very large as comment #1.

 
> > 3) Is guest being run with recommended kernel parameters?
> > 
> > 64-bit: notsc divider=10
> > 32-bit: clock=pmtmr divider=10
> 
> Yes.
Comment 4 Zachary Amsden 2011-01-13 18:25:45 EST
I believe the 32-bit kernel has no fine grained PM timer accounting, so worse drift is expected.  Not much we can do about this unless we plan to port fine grained PM timer fixes to 32-bit 4.8 kernel, but that is risky and a totally different code base.

Since this is a 4.8 issue, not a 5.X issue, I don't propose that we pursue that course of action.
Comment 5 Jiri Pallich 2012-06-20 11:56:37 EDT
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. 
Please See https://access.redhat.com/support/policy/updates/errata/

If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.

Note You need to log in before you can comment on or make changes to this bug.