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. > Also it's not clear which version of the driver you're talking about. In > the current kernel, stall_callback doesn't exist. I've been looking at the sources to 2.6.11. > > 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. > > In any case, by requesting NO_FSBR in the urbs from the storage > > driver, it appears that we prevent stall_callback from breaking the > > cycle in the work-to-do list, thus keeping the controller busy with > > our slow-to-respond transfers from iLO. If the uhci driver does break > > the cycle in the work-to-do list, > > I.e., if FSBR is turned off... > > > then our slow-to-respond transfers suffer > > their normal slowness plus the additional end-of-frame idle time (e.g. > > the UHCI controller hits the terminate bit and idles out the rest of > > the frame). > > Yes. That's why you have a maximum throughput of 64 bytes/ms when FSBR > is off. It doesn't explain why the printer should require 112 ms to > transfer 512 bytes; provided the maxpacket size for the bulk endpoint > is 64 the transfer shouldn't take more than 10 ms. BTW, we're talking about a usb storage device suffering here, not a printer. 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). > > But also, I am curious if we have some performance anomalies in > > uhci-hcd. They claim that "2.4 worked". What actually worked was > > probably usb-uhci, because that was default in RHL & RHEL. > > I find this patch very questionable. > > First, note that the OHCI drivers do not pay any attention to the NO_FSBR > flag. It would be interesting to see how the printer behaves with an OHCI > controller. > > Second, the UHCI driver isn't bound to observe the flag either. At some > point in the future the FSBR implementation is quite likely to change. 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. We don't see any problems like this on OHCI systems. Unfortunately, I know next to nothing about how OHCI controllers work, but I would speculate that they always have some sort of bandwidth reclamation happening on their bulk lists. > Third, the real question hasn't been answered. We still don't know why > the printer works so slowly. See above. Latency. --Chris ------------------------------------------------------- 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
