Handling multiple endpoints/pipes

I am looking for any guidance, surgestions or advise on handling multiple pipes/endpoints.

I have an embedded project that produces more data than I can get down one endpoint/pipe - I need to use three.

Is there are away to associate a ReadFile call to multiple pipes? My thinking is that in my IoRead call back where one would nominally make a call to WdfUsbTargetPipeFormatRequestForRead, I could probe the three pipes to see which has data and set up to return the data to the requestor from that pipe, but I am not sure how to probe the pipe yet, nor am I sure this is the right way to go.

Many thanks

Veronica Merryfield wrote:

I am looking for any guidance, surgestions or advise on handling multiple pipes/endpoints.

I have an embedded project that produces more data than I can get down one endpoint/pipe - I need to use three.

Color me extremely dubious. A single bulk pipe can saturate a USB cable
all by itself. You don’t gain more bandwidth by using multiple pipes.
Instead, you just divide the existing bandwidth between them.

The only exception is isochronous. A single isochronous pipe is limited
to 24MB/s, and most USB controllers can handle two of those.

Is there are away to associate a ReadFile call to multiple pipes? My thinking is that in my IoRead call back where one would nominally make a call to WdfUsbTargetPipeFormatRequestForRead, I could probe the three pipes to see which has data and set up to return the data to the requestor from that pipe, but I am not sure how to probe the pipe yet, nor am I sure this is the right way to go.

It’s not the right way to go. Perhaps you should describe your device
in more detail, so we can offer advice.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

My device is producing 1.49MB/s. Other than the control end point, I have a buffer limitation of 512 bytes per end point with double buffering and a total buffer space of 2368 bytes.

My understanding, perhaps incorrect, is that for a FS 1ms frame, an endpoint is transferred once which gives me a bandwidth of 512000 Bps implying that I need to use 3 end points. For HS, 8 endpoints could be transferred per 1ms frame, 1 per micro-frame.

In either case, I need to bring multiple pipes (bulk) come together in the driver to service a single ReadFile call.

Thanks

On 2010-08-20, at 10:38 AM, Tim Roberts wrote:

Veronica Merryfield wrote:
> I am looking for any guidance, surgestions or advise on handling multiple pipes/endpoints.
>
> I have an embedded project that produces more data than I can get down one endpoint/pipe - I need to use three.

Color me extremely dubious. A single bulk pipe can saturate a USB cable
all by itself. You don’t gain more bandwidth by using multiple pipes.
Instead, you just divide the existing bandwidth between them.

The only exception is isochronous. A single isochronous pipe is limited
to 24MB/s, and most USB controllers can handle two of those.

> Is there are away to associate a ReadFile call to multiple pipes? My thinking is that in my IoRead call back where one would nominally make a call to WdfUsbTargetPipeFormatRequestForRead, I could probe the three pipes to see which has data and set up to return the data to the requestor from that pipe, but I am not sure how to probe the pipe yet, nor am I sure this is the right way to go.

It’s not the right way to go. Perhaps you should describe your device
in more detail, so we can offer advice.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Veronica Merryfield wrote:

My device is producing 1.49MB/s.

Sorry, that exceeds the usable capacity of a full-speed USB bus. It is
simply not possible. You’ll need to switch to high-speed, or compress
the data.

My understanding, perhaps incorrect, is that for a FS 1ms frame, an endpoint is transferred once which gives me a bandwidth of 512000 Bps implying that I need to use 3 end points. For HS, 8 endpoints could be transferred per 1ms frame, 1 per micro-frame.

No, this depends entirely on the type of endpoint. With an interrupt
endpoint or an isochronous endpoint, the endpoint descriptor determines
how often you will get an opportunity to transmit, up to once per
frame. In a full speed device, a maximum-bandwidth isochronous endpoint
can do 1023 bytes per frame.

However, a bulk endpoint can do many packets in a single frame – as
many as will fit in the available bandwidth. The theoretical maximum
(with bus overhead) is 1.216 MB/s.

In either case, I need to bring multiple pipes (bulk) come together in the driver to service a single ReadFile call.

Even if that capacity were available, how would you expect to
synchronize them? You cannot rely on having data from multiple pipes
arrive neatly in order. Remember that the device cannot transmit
anything unless the host controller tells it to send, and the host
controller scheduling will not promise to alternate transfers in exactly
the order you want.

I’m sorry, but your design is flawed.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

The primary use case is a HS link with a data rate degradation for a FS link.

Each data packet starts with a sequence marker to enable data reconstruction.

Thank you for the info on a bulk endpoint - I did not glean this from the various docs.

On 2010-08-20, at 12:28 PM, Tim Roberts wrote:

Veronica Merryfield wrote:
> My device is producing 1.49MB/s.

Sorry, that exceeds the usable capacity of a full-speed USB bus. It is
simply not possible. You’ll need to switch to high-speed, or compress
the data.

> My understanding, perhaps incorrect, is that for a FS 1ms frame, an endpoint is transferred once which gives me a bandwidth of 512000 Bps implying that I need to use 3 end points. For HS, 8 endpoints could be transferred per 1ms frame, 1 per micro-frame.

No, this depends entirely on the type of endpoint. With an interrupt
endpoint or an isochronous endpoint, the endpoint descriptor determines
how often you will get an opportunity to transmit, up to once per
frame. In a full speed device, a maximum-bandwidth isochronous endpoint
can do 1023 bytes per frame.

However, a bulk endpoint can do many packets in a single frame – as
many as will fit in the available bandwidth. The theoretical maximum
(with bus overhead) is 1.216 MB/s.

> In either case, I need to bring multiple pipes (bulk) come together in the driver to service a single ReadFile call.

Even if that capacity were available, how would you expect to
synchronize them? You cannot rely on having data from multiple pipes
arrive neatly in order. Remember that the device cannot transmit
anything unless the host controller tells it to send, and the host
controller scheduling will not promise to alternate transfers in exactly
the order you want.

I’m sorry, but your design is flawed.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

“Veronica Merryfield” wrote in message
news:xxxxx@ntdev…
> The primary use case is a HS link with a data rate degradation for a FS
> link.

Well, this is interesting question, IMHO.
I’ve been in few projects when FS speed was not enough, and throttling on
the device side was
not feasible or too complex to implement.
The marketing agreed that the driver will gracefully fail when it detects FS
attachment.
But these products were not “mission critical”.

Regards,
– pa