My coworker is working on a project where USB 2.0 device exposes HID endpoint so only OS supplied drivers can be used. Communication protocol uses OUTPUT report to send a request to the device and received reply via INPUT report which is 512 bytes sized. Interrupt endpoint polling interval is set to 500 usec or less.
Everything works but the problem is with timing. XP SP2, Vista is surprisingly better. USB analyser shows device always responds to the request within less than 1 ms but the app doesn’t get the reply sooner than within 17 ms. From app point of view everything looks OK; it uses following sequence of operations:
- app calls overlapped ReadFile() to queue IRP for INPUT record
- ReadFile() returns pending status immediatelly
- app sends OUTPUT report using overlapped WriteFile()
- WriteFile() returns pending status almost immediatelly
- app waits for WriteFile() completion; also immediatelly
- app waits for ReadFile() completion which typically takes 17.8 ms regardless of computer used
The problem is time between #5 and #6. We used IrpTracker to see where time is consumed. It seems HidUsb driver has sent an IRP to lower USB driver even before app calls #2. This IRP is completed later and contains results which are returned to the app in #6. The time is spend between #5 and this IRP completion i.e. somewhere in OS USB drivers.
My question is if there is something what can app do to make things faster. And what causes the delay. It looks like IRP isn’t completed when interrupt EP data are read but about 16 ms later. Which looks like it isn’t completed when HC reads data but later by some thread which checks HC state periodically. Seems crazy but it wouldn’t be the first case I saw something like this.
Any idea appreciated.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]