Messages in this thread | | | Date | Mon, 16 Aug 1999 11:58:43 +0200 | From | David Olofson <> | Subject | Re: Prioritized I/O |
| |
Rogier Wolff wrote: > > David Olofson wrote: > > I'd split the problem i two parts; 1) start access time, and 2) > > guaranteed transfer rate. > > > > The distinction won't help much if you really need 1) all the time, but > > in most applications, you need 1) only when starting to _read_, and then > > 2) for the actual (buffered) streaming. > > > > For 1) there are all the problems with disk access time and other > > requests being processed when you need to get in, but for 2), "all" you > > Theorizing about this is good. But not too much. > > Why would you want a guaranteed start time?
If the data is requested by another system that's not able to predict events... I have to admit that I'm having more problems finding a legitimate reason for implementing such a feature, the more I think about it.
> When a user presses the "start" button, you would like to be able to > start immediatly playing that raw video stream at 6Mb per second?
Would be nice, but it's impossible.
Unless you define "immediately" as a well defined latency, and find a way to always have a filled buffer ready within that time after a request. Looks kind of pointless to me, _unless the current solutions result in a worst case latency more than a few times the average case_.
> If it's a user pressing that button, getting that guaranteed rate of > 6Mb per second is essential for the quality of the result. But waiting > for the 3Mb buffer to fill before starting, is not all that bad.
No, I agree, and this kind of applications wasn't what I had in mind. I was more like wondering why people really ask for something like that, and truing to point out the problems and a possible way to solve it if they really need it. So, does anyone really need hard real time response, or it it just a design problem of their applications?
As I failed to get it accross in the last post: ----------------------------------------------------------- My point is that low latency I/O is NOT the way to design a system with guaranteed streaming rate. Buffering is needed for many reasons anyway, most importantly to be able to get any usable rate. -----------------------------------------------------------
I'll be happy with guaranteed streaming rates and sane bounds on the start latency. (That is, I'd NOT accept to be blocked for 3 seconds when the average case is .5 seconds... That's far beyond what you can expect a demanding user to put up with.)
Sorry for being in Unfiltered Brain Storming Mode when I wrote that post. ;-)
//David
- 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/
| |