On Sat, 12 Nov 2005, Neil Brown wrote: > Thanks. It didn't go as well as I hoped, but I've made progress. > I tried: > - disabling the return channel, so input requests aren't sent > - forcing depth-first rather than breadth first traversal > - removing the FR-control queue altogether > - removing the isochronous queues all together > > and each of these seemed to make a small improvement (though given the > normal variance, I didn't do enough tests to give precise results). > > It seems that by giving the HC less work to do walking pointers in > QHs, the better it gets. This sounds weird, but I reduced the time for > my test job from 5 minutes to 55 seconds, and the last drop from about > 1:10 to 55 was through removing the isochronous queues > (setting > uhci->frame[i] = uhci->skel_int1_qh->link; > for all i). > > Maybe the printer is very sensitive to timing and the extra time it > takes the HC to walk this pointers makes a difference??? I'm not sure > I believe that, but it is the only explanation I can come up with so > far. Unfortunately it doesn't help me solve the real problem... > Is it possible to make fine adjustments to the clock that the HC uses? > (I know the USB is self clocked, and the gadget should just sync with > that, but something is definitely wrong, so I'm making wild guesses).
That sort of timing dependence really shouldn't exist. > During my explorations I think I found another typo. > > As I understand the code, if a URB takes longer than 50ms to complete, > it is switched to use depth-first traversal, presumably to give it more > bandwidth. I gather from the comments that it is meant to arrange for > 5 transactions to go for every loop around the QHs, rather than the > normal one. However this isn't what the code does. It actually > arranges for 2 to go out instead of 1 every 5 times around the loop. Yes, I've known about that typo for years. It doesn't really matter, because the entire FSBR implementation is going to be completely changed at some point not too long from now (I hope!). > Also, I'm not sure the 50ms is actually effective. It seems that the > timeout is implemented by the root-hub timer calling hub_status_data, > which it only does every 250ms. So it looks to me like it is really a > 250ms timeout before switching to depth-first. There's a parallel email thread with someone else at HP who's also seeing low performance. He says it's because their servers have a large startup latency for executing requests, and this causes the FSBR timer to expire, making everything go very slowly. You could try changing the IDLE_TIMEOUT value to something larger than 50 ms; maybe that will help. > However, I don't completely understand the code, so I'm probably > missing something. > One bit I don't understand is why FSBR is switched of for URBs which > have changed to depth-first. I cannot see any benefit in switching > off FSBE if there are any outstanding bulk URBs at all. The benefit is that it drastically reduces the controller's load on the PCI bus. If the URBs can't proceed because the device isn't ready, there's no reason for the controller to constantly access memory. 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
