* Re: HZ > 100 overhead
1999-10-27 17:42 HZ > 100 overhead est
@ 1999-10-27 18:31 ` Paul Barton-Davis
1999-10-27 18:55 ` Billy Biggs
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: Paul Barton-Davis @ 1999-10-27 18:31 UTC (permalink / raw)
To: linux-sound
>> >Wouldn't you say that an HZ > 100 kernel is the cleanest solution?
>>
>> its the cleanest, but not the best. HZ = 1000 adds about 8% overhead
>> to IRQ processing *all the time*.
>
>Are you *sure* about this? I seem to remember there was some debate
>about that figure on linux-kernel.
Ed Hall measured it, and my overall impression of Ed is that I'd trust
him to do this correctly. what did the l-k folks think ?
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: HZ > 100 overhead
1999-10-27 17:42 HZ > 100 overhead est
1999-10-27 18:31 ` Paul Barton-Davis
@ 1999-10-27 18:55 ` Billy Biggs
1999-10-27 20:39 ` Benno Senoner
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: Billy Biggs @ 1999-10-27 18:55 UTC (permalink / raw)
To: linux-sound
On Wed, 27 Oct 1999 est@hyperreal.org wrote:
> Paul Barton-Davis discourseth:
> > >
> > >Wouldn't you say that an HZ > 100 kernel is the cleanest solution?
> >
> > its the cleanest, but not the best. HZ = 1000 adds about 8% overhead
> > to IRQ processing *all the time*.
>
> Are you *sure* about this? I seem to remember there was some debate
> about that figure on linux-kernel.
Just to add to the confusion, I remember that this only adds significant
overhead on older machines. Regardless, a higher HZ value should be
standard, and switching back to a lower one (100) should be simply a
kernel config option.
This is all pretty controversial though.
#demoscene on irc.openprojects.net for people who support this idea. :)
#linux on linuxnet for some people who don't support this idea. :)
--
Billy Biggs vektor@div8.net
http://www.div8.net/billy wbiggs@uwaterloo.ca
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: HZ > 100 overhead
1999-10-27 17:42 HZ > 100 overhead est
1999-10-27 18:31 ` Paul Barton-Davis
1999-10-27 18:55 ` Billy Biggs
@ 1999-10-27 20:39 ` Benno Senoner
1999-10-27 23:59 ` Paul Barton-Davis
1999-10-28 0:16 ` Benno Senoner
4 siblings, 0 replies; 6+ messages in thread
From: Benno Senoner @ 1999-10-27 20:39 UTC (permalink / raw)
To: linux-sound
On Wed, 27 Oct 1999, Paul Barton-Davis wrote:
> >> >Wouldn't you say that an HZ > 100 kernel is the cleanest solution?
> >>
> >> its the cleanest, but not the best. HZ = 1000 adds about 8% overhead
> >> to IRQ processing *all the time*.
> >
> >Are you *sure* about this? I seem to remember there was some debate
> >about that figure on linux-kernel.
>
> Ed Hall measured it, and my overall impression of Ed is that I'd trust
> him to do this correctly. what did the l-k folks think ?
It depends on your box, a P133 might suffer much more than a PII400.
On a PII400 the performance his is very little IMHO (no actual numbers)
But we can't assume that HZ\x1000 for our multimedia apps.
Therefore my proposal is the following:
(similar to Eric's proposed rtcd)
In our upcoming multimedia API we will run the audio daemon
not only for providing PCM/MIDI services but precise timers too.
This could be implemented by choosing the most efficient method
at the moment:
that means: if you are runnnig with 1ms audio buffer sizes,
instead of firing up the RTC device, use the soundcard's timer
(combined with RDTSC) , to wakeup your clients.
comments ?
Benno.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: HZ > 100 overhead
1999-10-27 17:42 HZ > 100 overhead est
` (2 preceding siblings ...)
1999-10-27 20:39 ` Benno Senoner
@ 1999-10-27 23:59 ` Paul Barton-Davis
1999-10-28 0:16 ` Benno Senoner
4 siblings, 0 replies; 6+ messages in thread
From: Paul Barton-Davis @ 1999-10-27 23:59 UTC (permalink / raw)
To: linux-sound
>In our upcoming multimedia API we will run the audio daemon
>not only for providing PCM/MIDI services but precise timers too.
i hate to go on about this, but MIDI only programs shouldn't need to
depend on audio services to work. i might even want to run a MIDI
interface on a machine with no audio card at all - its hard to find an
argument to be using an audio daemon under such circumstances.
thats why i like eric's suggestion for an rtcd that can be used by
programs that want precise-ish timing *but have no option to do
audio-based timing* because they don't deal with audio. any program
that does its own audio output or input in small fragments has its own
built-in source of precise timing, but not every interesting program
works that way.
--p
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: HZ > 100 overhead
1999-10-27 17:42 HZ > 100 overhead est
` (3 preceding siblings ...)
1999-10-27 23:59 ` Paul Barton-Davis
@ 1999-10-28 0:16 ` Benno Senoner
4 siblings, 0 replies; 6+ messages in thread
From: Benno Senoner @ 1999-10-28 0:16 UTC (permalink / raw)
To: linux-sound
On Thu, 28 Oct 1999, Paul Barton-Davis wrote:
> >In our upcoming multimedia API we will run the audio daemon
> >not only for providing PCM/MIDI services but precise timers too.
>
> i hate to go on about this, but MIDI only programs shouldn't need to
> depend on audio services to work. i might even want to run a MIDI
> interface on a machine with no audio card at all - its hard to find an
> argument to be using an audio daemon under such circumstances.
>
> thats why i like eric's suggestion for an rtcd that can be used by
> programs that want precise-ish timing *but have no option to do
> audio-based timing* because they don't deal with audio. any program
> that does its own audio output or input in small fragments has its own
> built-in source of precise timing, but not every interesting program
> works that way.
>
> --p
Of course I agree, that you are not forced to run the audio server
all the time.
Do you remember the discussion some time ago ?
"the client can access the device directly or use the audio server"
"the client can do his own plugin hosting, or delegate the hosting to the audio
server"
In the case of the timer I'd opt for a similar solution.
( note that in my case the rtcd is a subsystem of the audio (or better
multimedia) engine )
I'm not sure if it is convenient to run the audioserver and rtcd in 2 separate
threads or if it's better to do all stuff in a single process (less scheduling
overhead ?)
The API should provide calls that let you allocate timers similar to the RTC
device, but where you can specify if the system is forced to use the RTC device
(in this case rtcd is used), or if you need only a generic timer with better
than x ms granularity.
In that case the engine could optimize and if it sees that PCM is runnnig (with
small fragments) , it could just use this timing source and wake up your app
when needed (via FIFO, socket etc.)
From an API point of view it should make no difference,
the client simply allocates a timer ressource , (with the possibility to
force some specific timer "ie I want to use RTC because I need 8192HZ
precision").
IMHO the advantage to integrate the rtcd into the multimedia engine
(which of course works on machines without soundcards) , is that
the system can optimize things when multiple timer sources are available.
We could even provide a way where the client "hosts" the timer in his own
thread, (like by your SIGIO notification), or by simply providing an RTC
wrapper, but with an uniform API.
That means if you run your Softwerk sequencer standalone (using the MIDI
device / timers directly (in this case the timer is managed though the
wrapper) ) ,
will work as well as when running it as a client to the multimedia engine:
MIDI events are feed to the engine via MIDI "pipe" to the server,
and timers are managed by the server.
= server wakes you up using the optimal method (or your preferred if you
forced this during the timer allocation) ).
efficient and flexible.
comments ?
Benno.
^ permalink raw reply [flat|nested] 6+ messages in thread