From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EADUl-0000RN-2l for qemu-devel@nongnu.org; Tue, 30 Aug 2005 17:18:15 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EADUg-0000Od-G5 for qemu-devel@nongnu.org; Tue, 30 Aug 2005 17:18:13 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EADUf-0000Kb-JP for qemu-devel@nongnu.org; Tue, 30 Aug 2005 17:18:09 -0400 Received: from [213.165.64.20] (helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.34) id 1EADNn-0001aC-4B for qemu-devel@nongnu.org; Tue, 30 Aug 2005 17:11:03 -0400 Subject: Re: Re: [Qemu-devel] Timing problems From: Sven Zenker In-Reply-To: <200508291001.39221.a_mulyadi@softhome.net> References: <1125257033.24800.28.camel@linux.site> <200508291001.39221.a_mulyadi@softhome.net> Content-Type: text/plain Date: Tue, 30 Aug 2005 17:08:19 -0400 Message-Id: <1125436100.9706.19.camel@linux> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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 Cc: qemu-devel@nongnu.org Hi, > 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 Yeah, you can also expect problems with the original versions on multi-processor machines, I would think. Would be nice to compare performance of the patched and original version. Unfortunately can't do that right now because timing of the non-patched version is of course messed up on my machine. > > 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().... rdtsc gives you the cpu's clock count, which, if CPU frequency changes, or your code is run on different processors (multiprocessor machine), cannot be assumed to be related to real time anymore. Resolutionwise, the real time clock may be inferior, of course, as Jim mentioned. Jim: could you point me to this other patch? Thanks! > > Another thing, IMHO it is better to use unified format (diff -u). More > readable and i think it is a standart Here you go: +++++++++++++++++++++++++++++++++++ qemu-0.7.1 # diff -u vl.c.org vl.c --- vl.c.org 2005-08-26 19:03:52.000000000 -0400 +++ vl.c 2005-08-28 14:43:00.000000000 -0400 @@ -500,16 +500,11 @@ } while (h != h1); return ((int64_t)h << 32) | l; } - #elif defined(__i386__) - int64_t cpu_get_real_ticks(void) { - int64_t val; - asm volatile ("rdtsc" : "=A" (val)); - return val; + return get_clock(); } - #elif defined(__x86_64__) int64_t cpu_get_real_ticks(void) @@ -591,18 +586,7 @@ void cpu_calibrate_ticks(void) { - int64_t usec, ticks; - - usec = get_clock(); - ticks = cpu_get_real_ticks(); -#ifdef _WIN32 - Sleep(50); -#else - usleep(50 * 1000); -#endif - usec = get_clock() - usec; - ticks = cpu_get_real_ticks() - ticks; - ticks_per_sec = (ticks * 1000000LL + (usec >> 1)) / usec; + ticks_per_sec = 1000000LL; /* our real time clock resolution */ } /* compute with 96 bit intermediate result: (a*b)/c */ +++++++++++++++++++++++++++++++++++ qemu-0.7.1/linux-user # diff -u main.c.org main.c --- main.c.org 2005-08-28 14:40:16.000000000 -0400 +++ main.c 2005-08-28 15:06:31.000000000 -0400 @@ -110,9 +110,7 @@ int64_t cpu_get_real_ticks(void) { - int64_t val; - asm volatile ("rdtsc" : "=A" (val)); - return val; + return get_clock(); } #elif defined(__x86_64__) +++++++++++++++++++++++++++++++++++ Best regards, Sven