But it wouldn't have achieved it using *any* specifically RT
techniques. The kernel just became preemptable, which is a necessary
and insufficient condition for hard RT. Given that a context switch is
a fully bounded event, its now "easy" to offer a guarantee of worst
case timing for the highest priority thread.
>You cannot ask for a timing guarantee and not ask for a RTOS -- and
>even most, so-called RTOS's don't provide this.
Au contraire. I think I have outlined a scenario that *would* provide
a timing guarantee, but would definitely not constitute an RTOS. Very
few people who currently need RTLinux or use QNX et alia would find
such a kernel adequate for their RT needs. Yet it would be adequate
for ours.
>> We know that if our thread does disk i/o or ends up paging, it could
>> block for an indeterminate amount of time. we know that if its uses
>> other system resources, it could fail to meet deadlines. thats
>> *OK*. we can design audio threads to do the right thing (and in fact,
>> we already do).
>
>What you want is a subset of services that are RT safe. That's
>very hard to do although it is not so hard to approximate.
The only subset that has to be RT safe is scheduling. The rest is not
part of the central issue here.
>> But as long as there is a the chance of a significant delay between
>> the interrupt that makes our SCHED_FIFO audio thread runnable again,
>> and it actually getting back on the processor, we can't make a number
>> of very useful (and very fun) things work correctly.
>
>I'm not advocating any particular approach to writing audio, but
>I am advocating some clarity about what you are asking for.
>I think that Linux that 99% of the time has no delays of more than
>10ms between set need_resched and process activation is an achievable
10ms is way too long. The numbers cannot go about 5ms, and would be
better around 2ms.
>and positive goal if done correctly. But if any 20ms delay over a, say
>4 hour period, might turn your CD master into junk, you have a hard
>realtime requirement and there is no way out of that.
this is a bit repetitive, but: we are NOT talking about applications
that do "static data movement". Burning CD's, playing back existing
audio streams, recording data: these are all manageable with the
current kernel (well, 2.2.13 and 2.3.51 were the last usable ones, I
think, but thats just a detail).
what doesn't work are applications that synthesize or process
audio+MIDI data in real-time. that is, they receive data that causes
dictates the contents of the next chunk of audio samples that they
output. this has nothing to do with multimedia as most people talk
about it.
yes, the deadlines are "hard". if they are missed, there is a glitch
in the audio output, and the program could be considered to have
failed. note, however, that each single failure has few long term
consequences for applications that are doing synthesis, and if it was
rare may even be acceptable for audio processing by comparison with
existing "dedicated h/w solutions".
but i continue to maintain that because the audio thread in these apps
can be reduced a purely computational process, with no memory, i/o or
other system resource issues, it can be solved (not that it *should*
be solved this way, but it can be) by using a fully-preemptable kernel
that does not satisfy most of the requirements of an RTOS.
--p
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/