On Thu, 10 Nov 2005, Frantz, Chris wrote: > On Thu, 10 Nov 2005, Alan Stern wrote: > > > > It appears that the stall callback is the thing that turns off FSBR > if > > > there has been an fsbr timeout. If an URB requests NO_FSBR, then > the > > > stall_callback can't turn off FSBR, so the host controller queues > > > remain linked in a cycle, and the controller continuously retries > > > transfers regardless of how long they're taking. > > > > You've got that exactly backward. If an URB requests NO_FSBR then it > > doesn't cause FSBR to be turned on in the first place. > > Perhaps. It seems to me that urbs requesting NO_FSBR have no effect > on FSBR at any time. That is to say, if FSBR is already on, then an urb > that requested NO_FSBR can't be responsible for FSBR getting turned off.
Correct. > > > but if some other URB turns on FSBR, urbs that didn't request it > seem > > > to benefit from it. I'm not sure if this is the behavior the > > > developer had in mind (not enough comments to read programmer > intent), > > > but it looks like that's how it works. > > > > That's also right. The idea is that FSBR is supposed to be turned on > > whenever somebody can make use of it. > > Which, to me, appears to be all the time, unless somebody explicitly > asks > to not turn it on. It's not "all the time". For instance, FSBR gets turned off when there there have been no active URBs for 50 ms. > BTW, we're talking about a usb storage device suffering here, not a > printer. Sorry, I confused your message with a separate but related email thread concerning throughput problems with an HP printer when using the 2.6 uhci-hcd driver. > The "iLO" product is an on-board management controller on HP Proliant > servers. The "Virtual Media" feature is very slow with the 2.6 kernel > versions of the UHCI driver. Because of the way virtual media works in > this product, there can be a large amount of latency servicing some of > the USB storage requests from the kernel (e.g. SCSI commands wrapped in > the bulk-only transport). Whenever there is more than 50ms of latency, > the driver appears to turn off FSBR and performance goes into the mud > (until the next command, where you get another chance to beat 50ms > responding). I have to agree that the way the driver handles FSBR is far from ideal. It's one of the things I'm planning to change, but lots of other changes are ahead of it in my queue. > I would agree that the patch is questionable. It appears the only > reason that it helps is that it takes advantage of some unintended > behavior of the FSBR implementation in the current UHCI driver. Does it help if you simply increase the IDLE_TIMEOUT value in the driver? How long are the large amounts of latency on your server? Alan Stern ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
