On Wed, 5 Apr 2006, Tommi Kyntola wrote:

> (I'm not on the list, so please cc me replies)
> 
> IN SHORT:
> I'm experiencing some weird behavior when sending control messages
> to USB endpoints using usb(dev)fs ioctls. Firstly, 2.6 is significantly
> slower than 2.4 (by a factor of 4). Secondly, consecutive calls
> appear to further damage the throughput, moreover this effect somehow
> can be reduced a bit by sleeping in between ioctl calls.
> 
> DETAILS:
> I'm sending 128 64byte control messages (uploading EZusb software
> to the devices). My main source of problems is that the control
> message latencies using 2.6.x kernels on a 300MHz machine is
> 4ms, which seems quite high, given that they used to be 1ms
> with 2.4 kernels.
> 
> I've been testing this with three x86 machines (300MHz, 1.3GHz
> and 3GHz) and with various kernels.
> 
> 2.4.x kernels have been tweaked to use HZ 1000.
> On 2.6 kernels it makes no difference whether I use 100 Hz, 250 Hz
> or 1000Hz and neither does the preempt setting seem to have any effect.
> 
>       2.4.x   2.6.x
> 300MHz        1ms     4.0ms
> 1.3GHz        -       1.0ms           (2.4 not tested due to lacking yukon2 
> driver)
> 3GHz  1ms     1.0ms
> 
> The latencies are accurately (within few percents) even milliseconds
> on 2.6 kernels. All those measurements were run on machines that have no other
> load whatsoever.
> 
> The very first ioctl call completes in about 1ms but after every call after
> that is slowed down.
> 
> The weird thing is that using 2.6 kernels that 4ms can be reduced to 2.0ms
> if I put a usleep(1000) between every ioctl call, making it 3ms per ioctl 
> call.
> THAT doesn't seem right. In the absence of the usleep somehow the next pending
> call seems to get slowed down quite a bit. This causes us some problems
> because our endpoints have onboard watchdog timers that occasionally bite 
> because
> the software upload takes too long.
> 
> I tried to browse the usb core and uhci sources, but I was unable to locate
> anything that could cause this. Some insight on the subject would be 
> appreciated.
> 
> Tested kernels are: 2.4.20pre5, 2.4.32 and all vanilla releases between 2.6.9
> and 2.6.16.1.
> 
> I'm willing to test any patch, tweak or kernel possible.
> Or if you want .configs, dmesgs or whatever, I'll be happy send that.

You implied that you're using uhci-hcd; is that right?

Has the device been configured when you perform the download?  If not, 
that would explain things.  uhci-hcd was changed recently to avoid doing 
Full Speed Bandwidth Reclamation for unconfigured devices, because some of 
them don't like it.  Without FSBR, a control transfer containing data 
takes a minimum of 3 ms.  (However this change was added only in 2.6.16.)

You should be able to speed things up considerably by transferring more
than 64 bytes per ioctl, assuming the device will support it.  Try doing 
4096 bytes instead.

Alan Stern



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to