USB Request Latency

USB PICs and the UBW

Moderator: phalanx

Post Reply
Posts: 6
Joined: Sun Sep 19, 2010 7:36 pm

USB Request Latency

Post by jrsimma » Tue Nov 23, 2010 4:55 pm

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?

Posts: 183
Joined: Sat May 27, 2006 5:43 pm
Location: 10 miles east of SFE

Re: USB Request Latency

Post by felis » Wed Nov 24, 2010 8:52 am

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.

User avatar
Support Volunteer
Posts: 1362
Joined: Sun Mar 05, 2006 9:23 pm

Re: USB Request Latency

Post by EmbeddedMan » Fri Nov 26, 2010 6:45 am

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.


Post Reply