Re: RT patch acceptance

Valdis.Kletnieks
2005-05-29T21:18:17Z

[-- Attachment #1: Type: text/plain, Size: 1925 bytes --]

On Sun, 29 May 2005 13:52:45 MDT, Zwane Mwaikambo said:

> i originally stated was that media applications are not common place as far
> as _hard_ realtime systems are concerned, this was in reply to Bill's
> emphasis on media applications.

Only because the average factory can afford the current "hard RT" gear, and
the average musician can't.

So the end result is that the factory doesn't have to pay for another part
ruined because a hole is drilled in the wrong place if the "hard RT" misses,
and the musician just has to resign themselves to "OK, let's try *another* take
and hope there's no POPs in it this time.." - even if the "hard RT" only ruins
a $5 part that you're making thousand a day, while the next take of the
musicians may cost a lot more than $5, and you don't get thousands of takes a
day.

At that point, the musician is cursing that he doesn't have "hard RT"....

(Of course, the musician doesn't *really* need a *totally* "hard RT" guarantee -
it would probably be quite sufficient if he lost only one take or two a month.
This is the sort of place where a "98% for 10% the cost" can win big...)

Yes, there's probably lots of *other* applications that would be written if
hard RT was available cheaply - but audio/video are a *known* area already.

> Terribly sorry old bean, but Linux isn't the center of the universe. I'm
> afraid Linux wasn't the push factor which led to the proliferation of
> multiprocessor systems.

Linux was *one* factor - the *point* was that we're seeing lots of things that
use clusters and massive parallelism that we *didnt* see when clusters weren't
financially feasible for many. So looking around the SMP landscape 7-10 years
ago, you'd have found only a few large sites doing it, and you would have said
"But people are doing A, B, and C on clusters, and almost nobody's doing X, Y
and Z on clusters" (pick any 3 X Y Z that have gotten big growth since).

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]