* [Qemu-devel] Re: Timing problems
2005-06-29 8:08 [Qemu-devel] Timing problems Alexander Toresson
@ 2005-11-07 22:46 ` Michael Smith
2005-11-08 15:24 ` Sven Zenker
0 siblings, 1 reply; 4+ messages in thread
From: Michael Smith @ 2005-11-07 22:46 UTC (permalink / raw)
To: qemu-devel
Alexander Toresson <alexander.toresson <at> gmail.com> writes:
> time flies by at 5x the speed it should.
> PS. I'm susprised nobody has seen this problem before. Is it just me
> who experience it?
No, I experience this as well.
I'm running Qemu 0.7.2 with Linux 2.6.14 (vanilla kernel) as host OS and Windows
XP Professional as guest OS. If the VM is running and actively using CPU, time
runs much faster in the guest than in the host. On the other hand, if the VM is
mostly idle, time is slower in the guest than in the host OS.
This odd clock behavior seems to cause other problems in the guest OS,
particularly during boot/service initialization.
I can recreate this behavior with or without KQemu.
I can recreate this behavior with or without CPU frequency scaling enabled.
It is frustrating, and I would be very happy if someone could suggest a fix or
workaround.
Thanks,
Mike Smith
mas3f@alumni.virginia.edu
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Qemu-devel] Re: Timing problems
2005-11-07 22:46 ` [Qemu-devel] " Michael Smith
@ 2005-11-08 15:24 ` Sven Zenker
0 siblings, 0 replies; 4+ messages in thread
From: Sven Zenker @ 2005-11-08 15:24 UTC (permalink / raw)
To: qemu-devel
Hi,
people have had this problem with SpeedStep machines, where it is
related to qemu timing being based on CPU cycle count, which is thereby
messed up.
Since it seems to occur with frequency scaling disabled as well, could
this be related to running on a HyperThreading CPU? Not sure what
happens there with the cycle counts, but to verify, you could try to
apply my previously posted patch that substituted the built-in mechanism
with realtime clock calls (was for 0.7.1, though, I think).
Best,
Sven
Am Montag, den 07.11.2005, 22:46 +0000 schrieb Michael Smith:
> Alexander Toresson <alexander.toresson <at> gmail.com> writes:
>
> > time flies by at 5x the speed it should.
>
> > PS. I'm susprised nobody has seen this problem before. Is it just me
> > who experience it?
>
> No, I experience this as well.
>
> I'm running Qemu 0.7.2 with Linux 2.6.14 (vanilla kernel) as host OS and Windows
> XP Professional as guest OS. If the VM is running and actively using CPU, time
> runs much faster in the guest than in the host. On the other hand, if the VM is
> mostly idle, time is slower in the guest than in the host OS.
>
> This odd clock behavior seems to cause other problems in the guest OS,
> particularly during boot/service initialization.
>
> I can recreate this behavior with or without KQemu.
>
> I can recreate this behavior with or without CPU frequency scaling enabled.
>
> It is frustrating, and I would be very happy if someone could suggest a fix or
> workaround.
>
> Thanks,
> Mike Smith
> mas3f@alumni.virginia.edu
>
>
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Qemu-devel] Re: timing problems
@ 2005-11-09 17:31 space-wizard
2005-11-09 18:55 ` Mike Swanson
0 siblings, 1 reply; 4+ messages in thread
From: space-wizard @ 2005-11-09 17:31 UTC (permalink / raw)
To: qemu-devel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 532 bytes --]
Hi!
I checked my QEMU and I found the same Problems. I'm running SLES9 (x86) on
an SLES9 (ppc) host. The target clock runs faster(? I've got positive
offsets running ntpdate ?) than the host clock. I've tried severel kernel
parameters (eg. clock=pit or clock=pmtmr) without any success.
The timing problems seem to be not only a problem with Windows XP as guest
os.
Best regards
christoph
--
Highspeed-Freiheit. Bei GMX supergünstig, z.B. GMX DSL_Cityflat,
DSL-Flatrate für nur 4,99 Euro/Monat* http://www.gmx.net/de/go/dsl
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Qemu-devel] Re: timing problems
2005-11-09 17:31 [Qemu-devel] Re: timing problems space-wizard
@ 2005-11-09 18:55 ` Mike Swanson
0 siblings, 0 replies; 4+ messages in thread
From: Mike Swanson @ 2005-11-09 18:55 UTC (permalink / raw)
To: qemu-devel
>From what I know, you'll just have to put up with it for now. Also, I
believe that ntpdate showing positive offsets means that the clock is
running slower. Run the date command before the ntpdate one to check
what the guest clock is at before the NTP update.
On 11/9/05, space-wizard@gmx.de <space-wizard@gmx.de> wrote:
> Hi!
>
> I checked my QEMU and I found the same Problems. I'm running SLES9 (x86) on
> an SLES9 (ppc) host. The target clock runs faster(? I've got positive
> offsets running ntpdate ?) than the host clock. I've tried severel kernel
> parameters (eg. clock=pit or clock=pmtmr) without any success.
>
> The timing problems seem to be not only a problem with Windows XP as guest
> os.
>
> Best regards
>
> christoph
>
> --
> Highspeed-Freiheit. Bei GMX supergünstig, z.B. GMX DSL_Cityflat,
> DSL-Flatrate für nur 4,99 Euro/Monat* http://www.gmx.net/de/go/dsl
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
--
Mike
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2005-11-09 18:55 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-11-09 17:31 [Qemu-devel] Re: timing problems space-wizard
2005-11-09 18:55 ` Mike Swanson
-- strict thread matches above, loose matches on Subject: below --
2005-06-29 8:08 [Qemu-devel] Timing problems Alexander Toresson
2005-11-07 22:46 ` [Qemu-devel] " Michael Smith
2005-11-08 15:24 ` Sven Zenker
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).