> > And there I was thinking "bandwidth reclamation" was > > for optimizing bandwidth usage, not pessimizing it! :) > > USB bandwidth, other busses don't matter... I think Pavel was suggesting that's not correct, and PCI bandwidth utilization is actually a significant issue. > But seriously, what should be the correct heuristic for that? Would it be practial to have the "one per frame" poll rate until an URB starts to see progress, and then try to "reclaim" that bandwidth till end-of-URB? That'd mean a max sized Ethernet packet (24 bulk packets) could take a frame or two more than necessary, but still much less than 24 frames. > Decreasing the > reclamation duration leads to problems with some devices (as a posting > recently showed...). No reclamation provides miserable USB bandwidth and > depth first sequence has no fair scheduling. I'm not sure I'd see unfair scheduling as a problem, unless there's starvation going on. And it's not like most folk have so many bulk USB devices that they'd notice the issue ... scheduled traffic is the way to get any "fairness" required. - Dave _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
