USB Request Latency

[jrsimma]

I've found no one yet that can answer the below questions definitively. Maybe YOU can be the first.

We designed and build a RS-232 and UDP/IP data acquisition system. It reads data and pushes it across RS-232 (or UDP/IP). However, with USB we have to wait for a request.

I've been told that when Windows, or Linux, gets busy it won't send those requests often. Maybe delayed for 250 milliseconds or longer. One solution would be to add SRAM so we could buffer information.

1) What are common solutions to the issue of the host OS, when it is busy, not sending USB requests often enough?
2) The above example is based on a bulk transfer. Would an isochronous transfer have the same issue? Or does the OS know iso requests are more critical.
3) What is the worse case latency we should design for (Windows and Linux). 250ms? 500ms?

[felis]

I've seen seconds between requests from a windows machine; you can't make your buffer big enough for that. Just make sure your buffer overrides on overflow so when the request comes the application gets the latest data. To request certain polling time use interrupt endpoint rather than isochronous.

[EmbeddedMan]

For a project long ago at work we had a similar problem, and did some testing. About %90 of the time Windows (XP in our case) was able to poll faster than every 10ms. Less than 1% of the time, there would be breaks in the polling as long as 4 seconds. Most breaks were far shorter, but every now and then there would be a long one. You just can't count on Windows to poll USB for you.

I believe using an Interrupt pipe may fix that problem, but in our case it wasn't an option.

*Brian