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