From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1E9a2i-0005Fy-8d
	for qemu-devel@nongnu.org; Sun, 28 Aug 2005 23:10:40 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1E9a2d-0005Dr-Us
	for qemu-devel@nongnu.org; Sun, 28 Aug 2005 23:10:38 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1E9a2d-0005Cj-BX
	for qemu-devel@nongnu.org; Sun, 28 Aug 2005 23:10:35 -0400
Received: from [66.54.152.27] (helo=jive.SoftHome.net)
	by monty-python.gnu.org with smtp (Exim 4.34) id 1E9Zxv-0007J7-HC
	for qemu-devel@nongnu.org; Sun, 28 Aug 2005 23:05:43 -0400
From: Mulyadi Santosa <a_mulyadi@softhome.net>
Subject: Re: Re: [Qemu-devel] Timing problems
Date: Mon, 29 Aug 2005 10:01:39 +0700
References: <1125257033.24800.28.camel@linux.site>
In-Reply-To: <1125257033.24800.28.camel@linux.site>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200508291001.39221.a_mulyadi@softhome.net>
Reply-To: a_mulyadi@softhome.net, qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org, Sven Zenker <Sven.Zenker@gmx.net>

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

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().... 

Another thing, IMHO it is better to use unified format (diff -u). More 
readable and i think it is a standart

regards

Mulyadi