Bug 665497

Summary: RHEL4.8-guest time drifts more than 13 seconds after 12 hours
Product: Red Hat Enterprise Linux 4 Reporter: Amos Kong <akong>
Component: kernelAssignee: Red Hat Kernel Manager <kernel-mgr>
Status: CLOSED WONTFIX QA Contact: Red Hat Kernel QE team <kernel-qe>
Severity: medium Docs Contact:
Priority: low    
Version: 4.8CC: ailan, michen, mkenneth, uobergfe, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-06-20 15:56:37 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 580948    

Description Amos Kong 2010-12-24 03:39:14 UTC 
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 20:44:44 UTC 
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 09:15:13 UTC 
(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-06 02:02:26 UTC 
(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 23:25:45 UTC 
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 15:56:37 UTC 
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.