Hi, I've been away for new years eve, therefore the delay... I try to answer/comment all mails you sent me on this subject.
> Try using a non-UHCI controller. Well, I would if I had one. But even if so, it would not solve my problem since the 'target' hardware in question has a uhci controller. > Axel, can you try it again, but this time, use the time command > to see what the CPU utilization looks like? The result looks like that: real 0m32.123s user 0m0.190s sys 0m0.038s So, as I expected the cpu speed seems not to be the problem. > In addition to what Johannes has mentioned, an important factor > is the overhead during submission of new requests. Axel didn't say > explicitly how his test program works, but if it waits for each > URB to complete before submitting the next URB then this could > be an important factor. I can easily imagine it explaining the > difference between the desktop and laptop timings. What I do is submit one urb, then wait for it (wait_event_interruptible_timeout() with a complete() in the complete handler of the urb), then queue the next urb. I can imagine that this causes the 'low' throughput when requesting many small transfers, but I can not see how this can explain the drop of throughput with large transfers, since the wait-for-requeue overhead decreases continuously. > I wonder if there is some other problem. Maybe adding some timing > information to the software portion of the TD would be interesting to > see if there are any delays between completing each individual TD. I would gladly try and test any patches that could help in tracking down the problem, but I fear I would heavily rely on your assistance since I have no knowledge of the internals of a hcd controller/software. > OTOH it seems uhci-hcd uses some better heuristics wrt. when to check > whether the urb timed out and how to go on then (DEPTH_INTERVAL). So I'm > not sure whether uhci-hcd FSBR timeout handling might explain the observed > results. Increasing FSBR_DELAY should tell. So, you suggest I look for a constant called FSBR_DELAY increase it and see if this influences my throughput? My old driver (2.4) did never queue an urb with a larger transfer_buffer that 64k. If the total buffer was larger than 64k, I simply resubmitted the urb in the complete handler with updated buffer pointer and buffer size. I can't remember why I did that and I thought with rewriting it for 2.6 I could make it 'proper'. Anyway, my old driver did not have this problem and I could do the same thing with 2.6. But I would rather help fixing it, but working around it. Thanks, Axel. ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
