On Thu, 5 Oct 2006, Christopher "Monty" Montgomery wrote: > On 10/5/06, Alan Stern <[EMAIL PROTECTED]> wrote: > > Bandwidth is allocated in the USB budget as soon as the first URB of a > > stream is submitted. That bandwidth remains allocated until the stream is > > interrupted, which happens whenever there are no URBs queued for the > > endpoint and the last completion handler has returned. > > Almost correct; in my scheduler, bandwidth remains allocated until the > stream is disabled.
The question is, how does a stream get disabled? > Otherwise any minor interruption in streaming > could cause an open/active endpoint to lose its bandwidth allocation > irrevocably. I don't know why you say "otherwise". If a minor interruption is enough to disable a stream then you're no better off. You never specified what disables a stream. > The only thing worse than having an underrun in a > professional situation is not being able to recover from the underrun > because bandwidth allocation is released and you might not be able to > get it back. > > In the past I have had to explain to my stage manager why I had to > restart a master audio controller in the middle of a show, losing all > foley and effects until it came back, because a USB audio device > underran and the USB subsystem did not recover. This is a situation I > never want to be in again. We did not and still do not have schedule > rebalancing in the EHCI driver. When an endpoint that's fit into a > schedule that's using > 90% of theoretical bandwidth loses its > allocation, it will not get it back because we can't currently recover > the fragmentation. > > > The only way a "gap" could arise is if something prevents the host > > controller driver from giving back a completed URB or the device driver > > from submitting a new URB in a timely manner. > > Correct. And that couldn't ever happen could it? :-) > > > When the new URB finally > > does get submitted too late, some of its transactions will get errors > > because they were not scheduled until after their time had already passed. > > ... by your description, the endpoint would have to be rebudgeted and > rescheduled, because the bandwidth was released as soon as the > underrun occured. No, that's not what I said. The way it's supposed to work is like this: The bandwidth is released as soon as the last completion handler callback returns, which has nothing to do with whether or not an overrun occurred. An overrun occurs when the completion handler fails to submit an URB in time for its slot. But as long as the completion handler submits any URB at all, it isn't the _last_ callback and so the bandwidth is not released. > In my patches, the bandwidth (and the budget) are > not released unless the device is closed (or endpoint disable is > called for some other reason). The previous situation was broken in a > very practical sense. I don't know the details of how ehci-hcd used to implement this. But waiting until endpoint_disable is wrong. > [BTW, Alan, I get the impression we did some amount of talking past > each other. Some of that might be terminology.] > > The scheduler, as I modified it, is actually two pieces; the budgeter > (which reserves bandwidth and makes timing decisions) and the > scheduler (which inspects the budget and manipulates the hardware > schedule). The scheduler is mostly unchanged from before, it just no > longer tries to do its own on-the-fly decision making. The scheduling > structure and conventions are mostly the same; the hardware schedule > is not really a round-robin, it only holds a few transactions at a > time, which are yanked as soon as they complete. The budget, however, > is a true round-robin. > > The old scheduler actually tore down an endpoint completely upon > underrun (if it managed to detect it, which due to bugs, it usually > didn't). If a new URB came in, it would restart the endpoint from > scratch, re-performing schedule and bandwidth allocation. It had no > idea how many things got missed, because an underrun was the practical > equivalent of calling close(). > > In the new scheduler, the budget is unaffected. When an underrun > occurs, the hardware scheduler merely skips over the schedule slots > that got missed, but does not drop the 'late' transactions when > they're submitted. Perhaps you are arguing that this is broken? Not at all; that's what it _should_ do. > I'd > have to agree; however, I am keeping with how the scheduler worked > before (if that had actually worked properly, which for the most part > it didn't). Returning an error on late transactions, such that the > transactions are dropped until the driver/app catches up, would be a > _change_ to the way things have always been since ISO support was > added. If it was broken before then it _deserves_ to be changed. However, if an URB is submitted so late that it has already missed _all_ of its slots, the submission should not return an error. I never suggested that it should. But the completion handler should quickly be called and all the frames should have an error status. > If you think we should bite the bullet and make that change, it would > not be particularly difficult from the schedule standpoint... at least > for ISO OUT. IN is a different problem; if we missed schedule slots, > the device probably overran, so we don't know how much data actually > got lost. We still end up with a latency shift even if we drop the > exact number of transactions that got missed. I get the feeling that neither the old way (as you describe it) nor your new way is correct. Missing schedule slots because an URB was submitted too late should not be enough to release the bandwidth reservation. That should happen if and only if the stream is broken, that is, if no more URBs are queued for the endpoint when a completion handler returns. Then so long as the completion handler submits a new URB, the bandwidth will remain reserved -- even if things run slow and a few slots are missed. And when the driver stops submitting URBs and the queue drains, then the bandwidth can be released right away. No need to wait for endpoint_disable; that might not happen until the device is unplugged. Alan Stern ------------------------------------------------------------------------- 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
