USB Timeout: what should time out, and does it work?

In the Castle USB API, it is (at least in theory) possible to specify a timeout when opening a pipe to/from an endpoint. But what exactly should time out?

If a message is being sent to a Bulk OUT endpoint, and the device endpoint only ever NAKs, should this time out?

If a message is being requested from a Bulk IN endpoint, and the device endpoint only ever NAKs, should this time out?

If a Bulk IN or OUT operation is being requested, is being NAK’d by the device, and the device is unplugged, should this time out?

What should time out?

Does the timeout work at all?

we will have to wait and see!!!

not so far

we will have to say no

But what exactly should time out?

The timeouts are applied to the individual USB-level transfers. I.e. if you’re reading 1MB of data but are using a 32KB buffer size then the transfer will get split up into several 32KB reads, each with your specified timeout.

The exact way the timeouts are implemented is down to each USB host controller driver, but AFAIK all the drivers implement it in the same way – if the transfer takes longer than the specified timeout period it will be failed. Duration of consecutive NAK responses doesn’t really come into it, except that if the device is sending too many NAKs it obviously results in a lower throughput – and so an increased chance of the timeout being hit.

If a Bulk IN or OUT operation is being requested, is being NAK’d by the device, and the device is unplugged, should this time out?

When a device gets disconnected, (assuming the USB drivers detect the disconnection), any outstanding transfers will be cancelled immediately with an error (although I can’t remember which – I think it may even be a timeout error)

Does the timeout work at all?

Yes.

Thanks for your response, Jeffrey.

In the Iyonix 5.18 version, what units are the timeouts specified in?

If a transfer never starts, does the timeout time out?

I’ve never knowingly got a timeout to time out, but it could be because I’m expecting it to work differently.

In the Iyonix 5.18 version, what units are the timeouts specified in?

Timeouts have always been specified in milliseconds

If a transfer never starts, does the timeout time out?

No. Only the currently active transfer for any given pipe will have its timeout in effect.

Timeouts have always been specified in milliseconds

I was aware that milliseconds were what appeared in Castle’s docs on the web. I assume what you’re doing there is confirming that their published information is correct.

No. Only the currently active transfer for any given pipe will have its timeout in effect.

So a transfer has to start (some data have to be transferred) before a timeout will ever take effect? That would be why I never see a timeout, then. The problem I have is that transfers never start and never time out either, thus making the (X)OS_GBPB call block. This was the nightmare I had a few years ago with MIDI, where you don’t know whether there will be any data at all on a bulk IN endpoint.

I think it would be more useful if the timeout also applied to the “never starts” situation, don’t you?

Another question: when doing (X)OS_GBPB to/from a bulk endpoint, does the buffer have to be in a DA or RMA? I’ve always assumed it could be in application workspace, which might explain the crashes, AODT etc. that I’ve been seeing.

I assume what you’re doing there is confirming that their published information is correct.

Yes. The timeout value that’s specified in the devicefs special field gets sent straight through to the NetBSD layer, which uses milliseconds.

So a transfer has to start (some data have to be transferred) before a timeout will ever take effect?

A transfer can be active/started before any data has been (successfully) transferred.

The problem I have is that transfers never start and never time out either, thus making the (X)OS_GBPB call block

I’m not actually sure how the errors get passed back to the OS file access functions. So it might be that the timeout is working, but OS_GBPB isn’t aware of it, and sits there trying to read from the devicefs stream.

Another question: when doing (X)OS_GBPB to/from a bulk endpoint, does the buffer have to be in a DA or RMA? I’ve always assumed it could be in application workspace, which might explain the crashes, AODT etc. that I’ve been seeing.

Application workspace should be fine.