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
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
(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.
(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.
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.
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.