Re: RT patch acceptance

[Bill Huey (hui) <bhuey@lnxw.com>]

On Sat, May 28, 2005 at 04:01:19AM -0700, Bill Huey wrote:
> On Sat, May 28, 2005 at 11:48:18AM +0100, Christoph Hellwig wrote:
> > Unfortunately my employment contract doesn't allow me to tell you the
> > details of GRIO.
> 
> SGI also released the XFS code to the public. I'm sure you can
> intelligently comment on that right and stop being a general ass ?

Obviously there's two kind of determinism going on:

1) submission of the IO request so that it arrives in a timely manner.
2) receiving and waking a thread to handle that data
3) RT decoding of the data so that it's frame locked.
4) repeat the cycles again.

If that loop is delivering drop free frames, then it's got to be
at least deterministic from the app decoding layers. If it's meeting
that, then it's also got to deliver that IO within that window or
at a rate greater than what it can buffer.

There's two kinds of determinism going on here, one CPU bound, the
other IO bound. A kernel with a 300 millisecond spike is obviously
going to violate that constraint on both fronts and make the
application glitch.

bill