[haiku] Re: Clock in Qemu
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku@xxxxxxxxxxxxx
- Date: Mon, 28 Dec 2009 20:42:04 +0100
On 2009-12-28 at 08:57:19 [+0100], Matt Veety <mveety@xxxxxxxxx> wrote:
> I noticed a problem with the clock in QEMU. While running it, I have
> noticed that the clock will count seconds faster than the duration of
> a second. I have looked through the code (and fooled around with it to
> a limited amount) and have been unable to pin-point the issue. If
> anyone has any ideas on how to fix it I would be very willing to help.
The main problem is that Haiku x86 uses the CPU's TSC for system and real
time computations and there's a range of processors with variable clock
rate that also change the TSC frequency (newer CPUs have a stable TSC
frequency again). The problem does not only exist under emulation, but also
on real hardware for, IIRC, one or two Intel processor generations with
Speed Step technology that would change the CPU frequency automatically
without software intervention.
The problem under emulation can usually be worked around. E.g. in Linux one
can specify power managements/performance profiles. Setting one that
wouldn't change the CPU frequency while running qemu should solve the issue.
For a real solution there are several options. One is obviously not to use
the TSC, but another, stable, time source. This has several problems:
* The TSC is ubiquiously available on all target CPUs (Pentium or later),
other time sources are not.
* The TSC method is quite cheap: Reading the TSC (can be done in userland)
and applying the multiplier costs only a few dozen cycles (I once measured
a difference of 18 ns between 2 subsequent system_time_nsecs() calls on my
Core i7-860). Any method that requires a syscall will take a few hundred
nanoseconds for the syscall overhead alone.
* The TSC has a pretty high resolution, which allows for fine-grained time
measurements with system_time_nsecs(). Other time source might not have
such a high resolution.
An alternative might be to continue using the TSC, but synchronize it with
a more stable time source periodically or on certain (ACPI) events. That
should make system_time[_nsecs]() only slightly more complex/expensive. The
synchronization part might not be trivial, though. Particularly so on
multi-CPU systems with diverging TSCs.
CU, Ingo
Other related posts:
