Alan Stern wrote:
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.
Actually we're using both, but the 300MHz I was referring to earlier has ohci.
I read through the control message handling again, and while I was searching
for timeouts earlier this time I checked the transfer size manipulation and
indeed
it passes the control message (given that it's no more than 4096) relatively
directly to the controller dma. (regardless of whether it's uhci or ohci, it
would seem)
Our electronics engineer (also responsible for the firmware) had stated
earlier that only 64byte packets are possible, but he seems to have neglected
the
fact that downloads using control messages are handled by the EZ usb
controller directly. The download in 2 4kb control transfers now takes only
7 or 8 ms each, totaling to 15ish ms, which is quite an improvement over the
600ish ms I experience earlier with 2.6.XX kernels. So the problem we had has
been solved.
((Oh, another thing while we're at it. As I now understand it, the ochi/uchi
controller HW then slices the 4096 TD into 64 byte usb frames that go down
the cable, yes?
And obviously the same thing happens with bulk messages. Given that the EZusb
would seem
to only have 64 bytes of memory for the incoming packet handling of bulk
messages.
Is it possible to send larges bulk messages (multiples of 64) to the EZusb
endpoint
which would then handle them one-by-one, but in one big transfer?
If so, then our card engineer has missed something quite essential about the
EZusb
specs... and there's quite a bit we can do also to speed up the bulk transfers
that follow the software download... ))
However, I'm still wondering why the usleep(1000) between the 64 byte control
transfers speeded up the process as a whole (i.e. it dropped the rate from
4ms/packet down to 3ms/packet). Not having looked into it any further,
I'm guessing that's a side-effect of the urb enqueuing mechanism or
some other anomaly that relates to the bandwidth control.
In either case it seems fishy.
cheers,
Tommi Kyntola
[EMAIL PROTECTED]
Raha-automaattiyhdistys RAY
Finland
-------------------------------------------------------
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
