[Qemu-devel] Re: timing problems
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
Re: [Qemu-devel] Re: timing problems
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, [EMAIL PROTECTED] [EMAIL PROTECTED] 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 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: Timing problems
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 [EMAIL PROTECTED] ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
