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/