From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1E9aYj-0006CY-Vg for qemu-devel@nongnu.org; Sun, 28 Aug 2005 23:43:46 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1E9aUk-0005iA-ST for qemu-devel@nongnu.org; Sun, 28 Aug 2005 23:39:46 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1E9aUe-0005cz-4P for qemu-devel@nongnu.org; Sun, 28 Aug 2005 23:39:32 -0400 Received: from [128.8.10.163] (helo=po1.wam.umd.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1E9aFn-00008E-7e for qemu-devel@nongnu.org; Sun, 28 Aug 2005 23:24:11 -0400 Date: Sun, 28 Aug 2005 23:21:52 -0400 From: "Jim C. Brown" Subject: Re: Re: [Qemu-devel] Timing problems Message-ID: <20050829032152.GA26595@jbrown.mylinuxbox.org> References: <1125257033.24800.28.camel@linux.site> <200508291001.39221.a_mulyadi@softhome.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200508291001.39221.a_mulyadi@softhome.net> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: a_mulyadi@softhome.net, qemu-devel@nongnu.org On Mon, Aug 29, 2005 at 10:01:39AM +0700, Mulyadi Santosa wrote: > Hello... > > > It simply > > replaces the virtual timer mechanism based on CPU tick count (which > > is totally messed up in a SpeedStep setting) with calls to the > > realtime clock. It should work even when emulation is stopped > > intermittently, I hope, since the built in "virtual clock stop" > > mechanism ist left unchanged. > > Hm..... hard choice.....correctness traded for perfomance.... But > anyway....IMHO this hack is needed for every speed-step enabled > machine. Perhaps...the other workaround is via cpufreqd? I don't have > any Pentium M based PC/laptop around, so this is just a pure guess > The other patch for this just used a constant to increment the time iirc (based on some value in /proc). > BTW, your patch seems reversed....if you really mean you want to fetch > realtime clock, you should use "rdtsc", right? But the patch seems > replaced "rdtsc" with get_clock().... > The values returned by rdtsc seem to vary depending on cpu frequency when speedstep is enabled. get_clock() is actually more accurate (tho i think less precise), at least from the user land POV. -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection.