From alsa-devel-owner@alsa.jcu.cz  Thu Jan 14 22:58:57 1999
Received: from renoir.op.net (root@renoir.op.net [209.152.193.4])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id WAA13082
	for <alsa-devel@alsa.jcu.cz>; Thu, 14 Jan 1999 22:58:17 +0100
Received: from someip.ppp.op.net (d-bm2-0b.ppp.op.net [209.152.194.43]) by renoir.op.net (o1/$Revision: 1.18 $) with ESMTP id OAA27251; Thu, 14 Jan 1999 14:26:57 -0500 (EST)
Message-Id: <199901141926.OAA27251@renoir.op.net>
To: alsa-devel@alsa.jcu.cz
Cc: Thomas Sailer <sailer@ife.ee.ethz.ch>
Subject: Re: [linux-audio-dev] Re: Linux scheduler issues. 
In-reply-to: Your message of "Thu, 14 Jan 1999 18:31:13 +0100."
             <369E29E1.8C42D728@ife.ee.ethz.ch> 
Date: Thu, 14 Jan 1999 14:28:06 -0500
From: Paul Barton-Davis <pbd@op.net>
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

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

I am guessing that at some point, the application I'm using this in is
going to end up with hand-crafted Pentium assembler code in order to
meet or beat the performance of the SHARC DSP for similar purposes.

Given this, I don't care much about portability at this level, and
anyway, the use of rdtsc is all wrapped in a C++ object that calls
gettimeofday() if PENTIUM_TSC is not defined.

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

That's pretty easy. I get the same answer, plus or minus 0.1 of a
cycle, as the kernel reports in /proc/cpuinfo. 

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

It doesn't. But sometimes, it does need to know the time at precisely
the same time that its facing a computation deadline. 

--p

