USB stream .Read() blocks for 1,5ms, even if ReadTimeout = 0


I’ve noted that on the FEZ Panda, looking for “new data” on a stream will consistently take 1,5ms if no data is available.

When data is available, that increases just a bit to 1,65ms.
The stream is set up with ReadTimeout = 0

Any idea why this polling is taking “so long” if no data is available?
PS: sending data is quite faster, sending 60 bytes is taking around 0,6ms.


USB packets come every 1ms

I see.
So this wouldn’t be any faster on a ChipworkX module - or?

It wouldn’t be faster on a 3Ghz processor :slight_smile:

There might be room for some improvement. We will look into it fo next releases.

Where is the data coming from? PC? You may be able to speed up the sending to the device - i.e. avoid missing too many 1mS slots - by changing the way you do this. Depends on the code and who/what’s sending it.

I’m sending the data from the PC (Mac 10.6).

I don’t really have to send much data back and forth - I just have to poll the FEZ, if the PC sent it a command to adjust some parameter.

I am poling if commands where sent from the PC every 40ms (that makes sense in my app!) - no matter if a command was received or not, read will take 1,5ms. That’s quite a lot :slight_smile:

Mike/Gus: it would be great if you could look into this. Some simple means to ask if data is available would be great. Something that returns fast - and helps deciding if a Read() should be done or not.

PS: do you have a bug-tracking / feature request database?

We keep track of them internally.