From alsa-devel-owner@alsa.jcu.cz  Thu Jan 14 18:31:59 1999
Received: from ife.ee.ethz.ch (ife-fast.ee.ethz.ch [129.132.24.193])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id SAA27231
	for <alsa-devel@alsa.jcu.cz>; Thu, 14 Jan 1999 18:31:17 +0100
Received: from ife.ee.ethz.ch (eldrich.ee.ethz.ch [129.132.24.203])
	by ife.ee.ethz.ch (8.8.5/8.8.5) with ESMTP id SAA04972
	for <alsa-devel@alsa.jcu.cz>; Thu, 14 Jan 1999 18:31:14 +0100 (MET)
Message-ID: <369E29E1.8C42D728@ife.ee.ethz.ch>
Date: Thu, 14 Jan 1999 18:31:13 +0100
From: Thomas Sailer <sailer@ife.ee.ethz.ch>
MIME-Version: 1.0
To: alsa-devel@alsa.jcu.cz
Subject: Re: [linux-audio-dev] Re: Linux scheduler issues.
References: <199901141441.JAA01271@renoir.op.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

Paul Barton-Davis wrote:

> True. But gettimeofday() costs about 450 cycles, and a gcc rdtsc asm
> macro costs about 66. When I've got 50usec to do a bunch of floating
> point computation, and I need to know the time, I know which one I'm
> going to use :)

But gettimeofday is much more portable :-) And it even copes with
some brokenness of rdtsc on some (non-intel) chips.

I guess you'll have to supply a macro jungle with assorted
autoconf macros to turn that rdtsc to rdtick on Sparc etc.

Also, rdtsc gives you the _cycle_ count, not the realtime,
so if you want realtime (and that's what you want when you're
looking for a clock_gettime(CLOCK_REALTIME) replacement),
you'll have to measure CPU frequency somehow.

Tom

NB: if you need to get the time every 50 usecs, then
your algorithm is probably a bit broken :-)

