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
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
timedrift is more than 13 seconds
timedrift is less than 0.5 second, not sure ?
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
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?
> 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
(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
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
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.