On 10/6/06, Alan Stern <[EMAIL PROTECTED]> wrote: > > In my primary use case, the endpoint will lose its bandwidth > > reservation, > > What makes you think that?
Bandwidth fragmentation. If we release an ISO stream's bandwidth from the middle of a schedule frame, we cannot currently recover the hole. EHCI makes rebalancing very difficult, and requires partially shutting down the schedule to do it. Each one of my devices requires a continuous > 9Mbps. There literally isn't room in the TT schedule for anything else (well, except the 20% left over for async). If any one of the endpoints xruns and that bandwidth is released, I have to shut eveything down and start from scratch to rebuild a working TT schedule where everything fits again. This is not theoretical. It will happen every time. OpenSolaris does not revoke an iso's bandwidth on XRUN. MacOSX does not revoke an iso's bandwidth on XRUN. NetBSD does not revoke bandwidth on XRUN. OpenBSD does not revoke bandwidth on XRUN. Why are we? It smacks more of elegant mis-design than correctness. Nothing I've read in the USB design supports this position as correct or desirable. > You still don't seem to understand. Kernel latency by itself _cannot_ > cause a bandwidth reservation to be lost. I call bullshit. A single well-placed printk inside the spinlock is enough latency to cause all the iso streams to lose sync. That spinlock can also be held be preemptible code. Etc. > Only the higher-level driver > can do that, by failing to keep the URB queue non-empty (i.e., by failing > to resubmit within its completion handler). If the HC clock gets to a slot that should be filled and it isn't, that's loss of sync. If the completion handler isn't called in time, the completion handler can't resubmit. Etc. We're not programming in a world where everything always goes according to plan. Leaving USB devices with guaranteed bandwidth requirements wide open to failure if anything unanticipated happens is just foolish. I agree that the current situation of only releasing bandwidth on endpoint_disable is in fact an error, and that wasn't my intent. I also submit it is preferable to the world ending on XRUN. An XRUN situation is *not* a shutdown situation. Monty ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
