On Mon, Jun 04, 2001 at 02:31:39PM -0700, David Brownell wrote:
> > > 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.
I know that, I forgot the :-)
> > 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.
That would need a one ms interrupt to inspect all running TDs, which sounds
like a much higher CPU usage. No real gain...
> > 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.
It is no problem to switch back to depth first, but then it is suboptimal
again for a device that NAKs very often...
--
Georg Acher, [EMAIL PROTECTED]
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
