分类： LINUX
2008-04-17 13:01:16
。在网上搜寻了半天，才发现不是操作系统本身的问题，应该是VMware的问题，于是开始从VMware着手，终于在官网找到关于VMware Guest OS时间过快/过慢的解决方案。| Clock in a Linux Guest Runs More Slowly or Quickly Than Real Time | ||||||||||
| ||||||||||
| ||||||||||
| ||||||||||
Why does the clock in my Linux guest consistently run more slowly or more quickly than real world time? | ||||||||||
| ||||||||||
Linux guest operating systems keep time by counting timer interrupts. Unpatched 2.4 and earlier kernels program the virtual system timer to request clock interrupts at 100Hz (100 interrupts per second). 2.6 kernels, on the other hand, request interrupts at 1000Hz — ten times as often. Some 2.4 kernels modified by distribution vendors to contain 2.6 features also request 1000Hz interrupts, or in some cases, interrupts at other rates, such as 512Hz.
Furthermore, an SMP-capable Linux kernel requests additional timer interrupts from the virtual local APIC timer. An SMP-capable kernel running on a one-CPU system generates twice as many total timer interrupts as the corresponding UP kernel, while such a kernel running on a two-CPU system requests three times as many. In general, an SMP-capable kernel running on
When a guest asks for more than 1000 clock interrupts per second, it can be difficult for the virtual machine to keep up, especially if other applications are running on the host at the same time. This can cause the clock in the guest operating system to fall so far behind real time that it is unable to catch up. The overhead of delivering so many virtual clock interrupts can also hurt guest performance and increase host CPU consumption.
It can also be difficult for the guest operating system to field 1000 clock interrupts per second. Even on real hardware, clock interrupts are sometimes lost because the operating system is busy for more than 1 millisecond and another clock interrupt comes in before the previous one was handled. Linux 2.6 contains code to detect such "lost ticks" and correct for them. Unfortunately, this code can trigger the correction spuriously in some cases, resulting in the Linux clock running more quickly than real time. This problem happens more often in a virtual machine than on real hardware, and can cause noticeable time gains. In some cases, the guest clock has been observed to run more than 10% more quickly than real time.
WorkaroundsIf your Linux 2.6 guest's clock is running too quickly, it indicates a problem with lost tick correction. Apply one of the workarounds in the section "Preventing the Clock from Running Too Quickly."
Note: The overcorrection for lost ticks has been fixed in Linux kernel 2.6.18. Upgrading to 2.6.18 or later also solves this problem.
If your guest's clock is running too slowly, it indicates that the host's real timer interrupt rate can't keep up with the guest's virtual timer interrupt rate. There are two approaches to dealing with the problem: either decrease the guest's rate or increase the host's rate. Apply one of the workarounds in the section "Preventing the Clock from Running Too Slowly." Also apply one of the workarounds for running too quickly, because correcting the first problem often reveals the second one.
In both cases, also make sure that VMware Tools is installed in your guest, that time synchronization is enabled and that you are not running any other clock synchronization software in the guest at the same time (such as ntpd).
If your host uses power management features (such as Intel SpeedStep, or AMD PowerNow or Cool'n'Quiet) that vary the processor speed, see .
Preventing the Clock from Running Too Quickly32-bit SystemsFor 32-bit systems, there are two kernel options that help with the guest kernel's over-correction for lost ticks:
64-bit SystemsIn the x86_64 Linux kernel, use the boot option notsc instead of clock=pit.
LILO example:
image=/boot/vmlinuz
label="linux" root=/dev/hda1 initrd=/boot/initrd.img append="resume=/dev/hda6 splash=silent notsc" read-only GRUB example: title Fedora Core (2.6.9-1.667)root (hd0,0) kernel /vmlinuz-2.6.9-1.667 ro root=/dev/hda2 notsc Preventing the Clock from Running Too SlowlyOne approach to a slow guest clock is to reduce the guest timer interrupt rate.
A different way to deal with a slow guest clock is to increase the host timer interrupt rate. Current versions of VMware products automatically increase the host's timer interrupt rate if needed, up to the maximum permitted by the host operating system. In some cases, though, you can increase this maximum.
|
