HID high speed interrupt transfer polling and PC latency

[AshAll]

Hello everybody,

I am working on the High speed HID interrupt transfer. In a loop, I use writefile and readfile to send and receive data in an alternating way. I am using overlapped transfer for reading. I started the PC side application in VC2005 from original Jan's usbhidoi for vc6.0.

There are three issues I see that I do not understand and would really like to get some help:

1. based on the firmware (with sam3u4e), the sam3u4e sends out the data always within 1us (it only reads an I/O line). But the PC's readfile function sometimes take more than 500ms to get the data back 

The polling interval I have set is 125us, the fastest for interrupt high speed transfer. So based on the protocol, PC's latency should be not more than 250us worst case. I am very confused.

2. For overlapped reading, I have a timeout definition to define. I found depending on what timeout value I set, the SourceUSB software reports roughly how long it takes to read the data (I/O line state) back. How can this happen, the readfile should return as soon as the data is read or timeout?

3. Since the firmware returns instantly, I was hoping to use a relatively larger timeout in waitforsingleobject (like 1ms) to get the data back before I issue the next writefile such that my execution can be sequentially. However, I find based on SourceUSB, the PC send a new OUT request before the previous IN request is successfully returned (and of course it was very late).

Any input is high appreciated!

Allall

[Jan Axelson]

The HID driver periodically sends IN token packets to request Input reports and stores received reports in a buffer. The frequency depends on the endpoint's bInterval.

A call to ReadFile returns when at least one Input report is available in the buffer or on a timeout if defined.

ReadFile doesn't cause any traffic on the bus; it just gets data from the buffer.

There is OS overhead in each call to ReadFile. I believe that is the delay you're seeing.

Jan

[AshAll]

Hi Jan,

Thanks so much for the clarification.

So can the OS overhead be as long as a half second?

Is there anyway to optimized this?

I am putting on a hardware protocol analyzer soon to test whether the firmware has any issue.

Thanks so much.

Ashall

[vanweric]

I am experiencing a similar problem.

I typically get 6-8ms round trip latency, but about 10% of the time I get 350ms.

I am using blocking reads and writes at the moment.  My machine is running 64 bit Windows Professional.

What additional information should I provide? I have USBlyzer traces if they would help.

Thank you!
 - Eric

[Jan Axelson]

The bottom line is that Windows isn't a real-time OS.

For greater throughput, the HID can use longer reports (with more data in each) or you can increase the ReadFile buffer size to retrieve multiple reports at once.

Closing other applications that might be taking the OS's time might help.

Jan

[AshAll]

Hi Jan,

Thanks for the response.

For the none real time windows operating system, we really can not do much.

I have tested my system for the firmware portion by toggling an I/O line starting from receiving the command to after the finishing the USB transfer, it seemed very accurate and never had execution variation of more than 1us. It does seems the PC side application (together with the whole windows OS) is causing the occasional slow down.

What I hope to understand is whether this is a problem with HID or interrupt based transfer in general. Especailly whether I am doing something wrong in my application.

I have another vendor control transfer + bulk transfer high speed USB device also connected to the same PC but on a different USB host. It seemed to work really accurate about the timing. No big timeout happens without our interrupt based HID connected to the same PC. It does occasionally really slow down (500ms in extreme) when the HID is on.

Any thoughts?

Really appreciate your help!

Ashall

[Tsuneo]

Hi AshAll,

Windows HID class driver has delay trouble on the interrupt OUT pipe, since Windows XP. MS has put patches on this issue from OS version to version, SP to SP. Patch on patches as usual MS way. In this way, the delay varies according to OS version and SP, and also with/without hub (incredibly, HID class driver affects to hub port driver). In this reason, query-reply communication model over HID interrupt OUT/IN is not recommended on Windows, when you need certain deadline on response time, ie. in real-time process.

For status query, like above port bit change, the query-reply model is replaced with status-change-report model. The device watches the status (port) change periodically by itself (usually, on SOF interrupt). When the device detects any status change, it notifies to host of the new status over HID interrupt IN pipe. On the PC application, an OVERLAPPED ReadFile call (or equivalent) always waits for status change notification from the device. This communication model can be mixed with query-reply model, by using a tag (or report ID) for each input report.

For query-reply model, you may apply HidD_SetOutputReport() (over control transfer), instead of HID interrupt OUT pipe. HidD_SetOutputReport() takes more time than OUT pipe, but its response time doesn't vary so uncertainly as OUT pipe.

You'll see this trouble just on HID interrupt OUT pipe. Other drivers, WinUSB, etc., have no problem on interrupt OUT pipe.

Tsuneo

[vanweric]

I hooked up a protocol analyzer and found that my device was the culprit, not Windows.  It would continuously NAK for 350+ ms at a time.