On Wednesday November 16, [EMAIL PROTECTED] wrote: > On Wed, 16 Nov 2005 09:54:41 +1100, Neil Brown <[EMAIL PROTECTED]> wrote: > > > > It would also be worthwhile to see if you can get more or less the same > > > effect without all those changes, just by increasing IDLE_TIMEOUT to 1000 > > > ms or something like that. > > > > I did get similar throughput with IDLE_TIMEOUT set to 50000. 1000 > > wouldn't be enough with 8K writes, as an 8K write often takes more > > than one second. But I'm happy to redo some tests to be able to give > > you clear before/after results. It'll probably have to wait a week or > > so, as I've spent more time on this that I really should have lately. > > I don't understand why this happens. The HCD (uhci-hcd) knows when > the bus is actually idle, so it can know when to set the timeout. > Strange.
The uchi-hcd decides that if a single URB takes longer than 50msec, then continuing with FSBR is a waste of PCI bandwidth, and it switches of FSBR and so it just sends one packet every millisecond (or 2 every 4th millisecond). This makes sense for a device that is sane but slow (though it should try more per frame, and would but for a typo) and doesn't fit well with an insane printer that wants packets in 1msec bursts every 112 msecs. i.e. it doesn't just set the timeout when the bus is idle, but also when the device appears idle, and in my case the appearance is deceiving. NeilBrown ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
