Subject: Re: [linux-audio-user] gnome-terminal performance
From: Lee Revell (rlrevell_AT_joe-job.com)
Date: Sun Aug 01 2004 - 03:03:13 EEST
On Sat, 2004-07-31 at 18:41, Florin Andrei wrote:
> On Sat, 2004-07-31 at 14:19, Lee Revell wrote:
>
> > If jackd were running SCHED_FIFO aka realtime, and gnome-terminal as a
> > normal priority process, it would be a bug (priority inversion) if
> > gnome-terminal *ever* interfered with jackd's operation.
>
> Well, i thought Linux can provide only soft realtime, so the
> interference is not totally out of question (like it would be on systems
> that can do hard or "true" realtime). Am i missing something?
>
It's not "hard realtime", which is where missing a deadline is
considered a fatal error, and is *never* allowed. The Mars Rovers are a
hard RT - if you are *ever* too late in responding to a 'move wheel'
command, that's it - mission over. It might as well have blown up. A
Cisco BTS (soft switch) is another example. No matter what else the
system is doing, it is not allowed to drop packets under load, or there
would be audible defects. For a cell tower, you could get away with a
soft realtime system, as people *expect* cell phones to suck. OTOH a
BTS has to be every bit as reliable as a hardware phone switch - that
could be someone's 911 call you are dropping, and people expect land
lines to just work, 100% of the time.
In hard-RT systems like this, *every* code path will have been
extensively audited, and tested, then audited some more, until there are
*no* unknowns. In practice, something like a satellite or a Mars rover
is way too complicated to audit every code path with mathematical rigor,
so get it as good as they can, then build in massive redundancy.
Doesn't matter how you achieve it, but the failure rate must be zero.
"Soft realtime", which is what we want, doesn't guarantee that it will
*never* miss a deadline - just that it shouldn't happen too often. BEOS
and IRIX were designed as "soft-realtime" systems, designed in order to
give the lowest possible latency.
Indeed, any time you put a soundcard in a computer you are dealing with
a soft realtime system, because from the time you start capture or
playback audio, you have to get scheduled in time to process the next
block, or you get a gap in the recording. An audible glitch in playback
or recording means the system has failed, just as you would consider the
system to have failed if you copied a file from one disk to another and
it got corrupted. It's actually worse because you cannot go back and
fix the problem. Since any useful system would have to meet these
requirements, "soft realtime" is not used as much - it's just the way
the system is supposed to work.
Generally "realtime" on the linux audio lists refers to soft realtime.
'RT' or 'Hard-RT' means hard realtime.
Lee
This archive was generated by hypermail 2b28 : Sun Aug 01 2004 - 03:07:00 EEST