srinivaskumar.r@in.bosch.com wrote:
I am trying to measure the performance of my USB driver. My driver sits on top of ACPI/usbhub in device stack.
HW is configured for USB 2.0 high speed; with 2 BULK points.
From a user space test app, WriteFile API delivers 40 bytes of REQUEST data. Data is written correctly. For each 40 bytes of REQUEST, HW gives back 15 bytes of ACK and followed by 40 bytes of RESPONSE. ( There will be constant delay of 60 uSec between ACK and RESPONSE ).
This is simply not a scenario for which USB was optimized. No scenario
which requires call-and-response will ever approach maximum speed.
That’s just a natural side effect of the design of USB. Remember that
USB frames are all scheduled in advance. If you do not have a request
ready and waiting when a frame is scheduled, then you will miss that
frame. You won’t get another chance until the next frame is scheduled.
My design goal is to have as much less time as possible between each REQUESTs. Currently I see that the Round trip is anywhere between 450 - 700us in USBlyzer ( elapsed time between 2 consecutive REQUESTs.)
Yep.
Now I AM NOT CLEAR AS WHY USB IS TAKING MORE THAN ~ 400usec. I see some serious design flaw in my approach of BULK mode.
Before pointing to the FIRMWARE on code change to INTERRUPT, I need some pointers to improvement to ways to measure the actual time.
The endpoint type won’t make a difference. Having an interrupt endpoint
guarantees you a slot in the frame, but once again if you don’t have a
request ready and waiting when the frame is scheduled, you’ll miss your
shot. You need to change your design so you can stream multiple packets
and ack/nak a bunch of packets at a time.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.