need practical throughput estimate for bulk endpoints

hi all:

I need to get an idea of what is practically achievable for USB 1.1 bulk endpoint throughput.
Given a system that has one bulk in and one bulk out endpoints in use (no other endpoints in use), what is a practical rule of thumb of the throughput you’ll get?

I realize there is some overhead as described in the 1.1 spec, and some over head for when either side is not ready, but I want to know what people really have been seeing? I think the controller we are using has a 64 byte fifo.

It is unreasonable to achieve a 50% efficiency (50% of 12 Mbps)?

It’s a hard pill for me to swallow when I hear somebody tell me that getting 16% efficiency is a reasonable value due to overhead.
What have you all been seeing? Even worse case would be good for me!

thanks in advance

By the way, I did take look at the USB 1.1 spec and the usb.org forum. Here’s what I found, including some info that was confusing.
I’ve posted on the usb.org forum as well, but I’m hoping somebody on this newsgroup will also respond.

In section 5.0 of the USB 1.1 spec, the table 5-6 on page 48 shows the bulk transaction limits. For a 64 byte transfer, the number of useful (non-protocol, I think this means) data bytes/frame is 1216. With a frame = 1 ms, this would be 1.2 Mbytes/sec.

(1) Since specs are theoretical, I went to the usb.org website and found a Q/A in which somebody asked what actual data rates look like on USB. I’ve pasted it in below. My question is if they meant 900 kilobits per second or 900 kilobytes per second?

If the theoretical max is 12 Mbits-per-second, then 900 kbits/sec would be (900 kilo-bits-per-sec / 12000 kilo-bits-per-sec) * 100 = 9/120 * 100 = 7.5% of theoretical throughput.

If the actual throughput is instead 900 K bytes per second, the actual throughput would be (900 K bytes per sec * 8 bits/byte) / 12000 kilo bytes per second * 100 = 60%, which makes more sense to me.

(2) Can somebody give me an idea of what the actual throughput values they have seen for bulk endpoints? The host is a PC running Windows XP SP2 and the device has what I think is a 64 byte fifo. The packets being transferred are 64 bytes long. I do realize that there are also dependencies as to whether either the host or target is ready to receive/send data, etc, but I was hoping to get a typical value.

http://www.usb.org/developers/usbfaq/#band1http:
1. What do actual data rates on USB look like?
A: USB’s actual throughput is a function of many variables. Typically, the most important ones are the target device’s ability to source or sink data, the bandwidth consumption of other devices on the bus, and the efficiency of the host’s USB software stack. In some cases, PCI latencies and processor loading can also be critical.
Assuming only the target endpoint consumes a significant amount of bus bandwidth-and both the target and the host are able to source or sink data as fast as USB can move it-the maximum attainable bandwidth is a function of the transfer type and signaling rate. These bandwidths are given in chapter 5 of the USB Specification. In practice, most hosts can reach the maximum isochronous and interrupt bandwidths with a single target endpoint. With bulk transfers, typical transfer rates are around 900kb/s to a single endpoint, increasing to near ideal transfer rates with multiple endpoints

----- Original Message -----
From: S. Drasninmailto:xxxxx
To: Windows System Software Devs Interest Listmailto:xxxxx
Sent: Wednesday, August 24, 2005 11:28 AM
Subject: [ntdev] need practical throughput estimate for bulk endpoints

hi all:

I need to get an idea of what is practically achievable for USB 1.1 bulk endpoint throughput.
Given a system that has one bulk in and one bulk out endpoints in use (no other endpoints in use), what is a practical rule of thumb of the throughput you’ll get?

I realize there is some overhead as described in the 1.1 spec, and some over head for when either side is not ready, but I want to know what people really have been seeing? I think the controller we are using has a 64 byte fifo.

It is unreasonable to achieve a 50% efficiency (50% of 12 Mbps)?

It’s a hard pill for me to swallow when I hear somebody tell me that getting 16% efficiency is a reasonable value due to overhead.
What have you all been seeing? Even worse case would be good for me!

thanks in advance


Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com</mailto:xxxxx></mailto:xxxxx></http:>

900 kiloBytes/sec is reasonable value which can be achieved without data lost. We have a “dumb” USB device which generates data stream which has to be captured by PC. Data rate can be controlled and I made some experiment several months before. If I remember correctly, I was able to capture 900 kB/sec with no problem (8 - 16 4 kB buffers always pending) and the maximal data rate was about 1.1 MB/sec but I don’t remember the exact value. Our device normally operates at ~800 kB/sec which is no problem to capture but overlapped IO is a must. We also use 64 bytes bulk endpoints and USB 1.1. I experimented at dual PIII/933 MHz; with faster machine results can be even better.

BTW, units are case sensitive and if used correctly, there wouldn’t be a problem with understanding. kb != kB

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]


From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of S. Drasnin[SMTP:xxxxx@msn.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, August 25, 2005 12:33 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] need practical throughput estimate for bulk endpoints

By the way, I did take look at the USB 1.1 spec and the usb.org forum. Here’s what I found, including some info that was confusing.
I’ve posted on the usb.org forum as well, but I’m hoping somebody on this newsgroup will also respond.

In section 5.0 of the USB 1.1 spec, the table 5-6 on page 48 shows the bulk transaction limits. For a 64 byte transfer, the number of useful (non-protocol, I think this means) data bytes/frame is 1216. With a frame = 1 ms, this would be 1.2 Mbytes/sec.

(1) Since specs are theoretical, I went to the usb.org website and found a Q/A in which somebody asked what actual data rates look like on USB. I’ve pasted it in below. My question is if they meant 900 kilobits per second or 900 kilobytes per second?

If the theoretical max is 12 Mbits-per-second, then 900 kbits/sec would be (900 kilo-bits-per-sec / 12000 kilo-bits-per-sec) * 100 = 9/120 * 100 = 7.5% of theoretical throughput.

If the actual throughput is instead 900 K bytes per second, the actual throughput would be (900 K bytes per sec * 8 bits/byte) / 12000 kilo bytes per second * 100 = 60%, which makes more sense to me.

(2) Can somebody give me an idea of what the actual throughput values they have seen for bulk endpoints? The host is a PC running Windows XP SP2 and the device has what I think is a 64 byte fifo. The packets being transferred are 64 bytes long. I do realize that there are also dependencies as to whether either the host or target is ready to receive/send data, etc, but I was hoping to get a typical value.

http:
> 1. What do actual data rates on USB look like?
> A: USB’s actual throughput is a function of many variables. Typically, the most important ones are the target device’s ability to source or sink data, the bandwidth consumption of other devices on the bus, and the efficiency of the host’s USB software stack. In some cases, PCI latencies and processor loading can also be critical.
> Assuming only the target endpoint consumes a significant amount of bus bandwidth-and both the target and the host are able to source or sink data as fast as USB can move it-the maximum attainable bandwidth is a function of the transfer type and signaling rate. These bandwidths are given in chapter 5 of the USB Specification. In practice, most hosts can reach the maximum isochronous and interrupt bandwidths with a single target endpoint. With bulk transfers, typical transfer rates are around 900kb/s to a single endpoint, increasing to near ideal transfer rates with multiple endpoints>
>
>
> ----- Original Message -----
> From: S. Drasnin mailto:xxxxx
> To: Windows System Software Devs Interest List mailto:xxxxx
> Sent: Wednesday, August 24, 2005 11:28 AM
> Subject: [ntdev] need practical throughput estimate for bulk endpoints
>
> hi all:
>
> I need to get an idea of what is practically achievable for USB 1.1 bulk endpoint throughput.
> Given a system that has one bulk in and one bulk out endpoints in use (no other endpoints in use), what is a practical rule of thumb of the throughput you’ll get?
>
> I realize there is some overhead as described in the 1.1 spec, and some over head for when either side is not ready, but I want to know what people really have been seeing? I think the controller we are using has a 64 byte fifo.
>
> It is unreasonable to achieve a 50% efficiency (50% of 12 Mbps)?
>
> It’s a hard pill for me to swallow when I hear somebody tell me that getting 16% efficiency is a reasonable value due to overhead.
> What have you all been seeing? Even worse case would be good for me!
>
> thanks in advance
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
></mailto:xxxxx></mailto:xxxxx></http:>

Thanks for the reply!

Did you (or one of your team members) program the usb device? If so, do you know how big the fifos were in the usb controller? Do you know how big the typical fifo is for bulk endpoints on the usb controller hardware? I was surprised at the 64 byte packet. I thought it might be 2 times the max packet size so that perhaps the control could ping pong between the two buffers and give the software time to empty one while the other was filling.

Also, how big were the buffers that you send down to the lowest level driver (which breaks them into 64 byte packets)? I would think that having the buffer you pass down being a multiple of 64 bytes (the low level packet size) would make the transfer rate faster.

thanks

----- Original Message -----
From: Michal Vodickamailto:xxxxx
To: Windows System Software Devs Interest Listmailto:xxxxx
Sent: Wednesday, August 24, 2005 3:49 PM
Subject: RE: [ntdev] need practical throughput estimate for bulk endpoints

900 kiloBytes/sec is reasonable value which can be achieved without data lost. We have a “dumb” USB device which generates data stream which has to be captured by PC. Data rate can be controlled and I made some experiment several months before. If I remember correctly, I was able to capture 900 kB/sec with no problem (8 - 16 4 kB buffers always pending) and the maximal data rate was about 1.1 MB/sec but I don’t remember the exact value. Our device normally operates at ~800 kB/sec which is no problem to capture but overlapped IO is a must. We also use 64 bytes bulk endpoints and USB 1.1. I experimented at dual PIII/933 MHz; with faster machine results can be even better.

BTW, units are case sensitive and if used correctly, there wouldn’t be a problem with understanding. kb != kB

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.comhttp:</http:>]

> ----------
> From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.commailto:xxxxx] on behalf of S. Drasnin[SMTP:xxxxx@msn.com]
> Reply To: Windows System Software Devs Interest List
> Sent: Thursday, August 25, 2005 12:33 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] need practical throughput estimate for bulk endpoints
>
> By the way, I did take look at the USB 1.1 spec and the usb.org forum. Here’s what I found, including some info that was confusing.
> I’ve posted on the usb.org forum as well, but I’m hoping somebody on this newsgroup will also respond.
>
> In section 5.0 of the USB 1.1 spec, the table 5-6 on page 48 shows the bulk transaction limits. For a 64 byte transfer, the number of useful (non-protocol, I think this means) data bytes/frame is 1216. With a frame = 1 ms, this would be 1.2 Mbytes/sec.
>
> (1) Since specs are theoretical, I went to the usb.org website and found a Q/A in which somebody asked what actual data rates look like on USB. I’ve pasted it in below. My question is if they meant 900 kilobits per second or 900 kilobytes per second?
>
> If the theoretical max is 12 Mbits-per-second, then 900 kbits/sec would be (900 kilo-bits-per-sec / 12000 kilo-bits-per-sec) * 100 = 9/120 * 100 = 7.5% of theoretical throughput.
>
> If the actual throughput is instead 900 K bytes per second, the actual throughput would be (900 K bytes per sec * 8 bits/byte) / 12000 kilo bytes per second * 100 = 60%, which makes more sense to me.
>
> (2) Can somebody give me an idea of what the actual throughput values they have seen for bulk endpoints? The host is a PC running Windows XP SP2 and the device has what I think is a 64 byte fifo. The packets being transferred are 64 bytes long. I do realize that there are also dependencies as to whether either the host or target is ready to receive/send data, etc, but I was hoping to get a typical value.
>
>
>
> http:>
> 1. What do actual data rates on USB look like?
> A: USB’s actual throughput is a function of many variables. Typically, the most important ones are the target device’s ability to source or sink data, the bandwidth consumption of other devices on the bus, and the efficiency of the host’s USB software stack. In some cases, PCI latencies and processor loading can also be critical.
> Assuming only the target endpoint consumes a significant amount of bus bandwidth-and both the target and the host are able to source or sink data as fast as USB can move it-the maximum attainable bandwidth is a function of the transfer type and signaling rate. These bandwidths are given in chapter 5 of the USB Specification. In practice, most hosts can reach the maximum isochronous and interrupt bandwidths with a single target endpoint. With bulk transfers, typical transfer rates are around 900kb/s to a single endpoint, increasing to near ideal transfer rates with multiple endpoints>
>
>
> ----- Original Message -----
> From: S. Drasnin mailto:xxxxx>
> To: Windows System Software Devs Interest List mailto:xxxxx>
> Sent: Wednesday, August 24, 2005 11:28 AM
> Subject: [ntdev] need practical throughput estimate for bulk endpoints
>
> hi all:
>
> I need to get an idea of what is practically achievable for USB 1.1 bulk endpoint throughput.
> Given a system that has one bulk in and one bulk out endpoints in use (no other endpoints in use), what is a practical rule of thumb of the throughput you’ll get?
>
> I realize there is some overhead as described in the 1.1 spec, and some over head for when either side is not ready, but I want to know what people really have been seeing? I think the controller we are using has a 64 byte fifo.
>
> It is unreasonable to achieve a 50% efficiency (50% of 12 Mbps)?
>
> It’s a hard pill for me to swallow when I hear somebody tell me that getting 16% efficiency is a reasonable value due to overhead.
> What have you all been seeing? Even worse case would be good for me!
>
> thanks in advance
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256http:
>
> You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.commailto:xxxxx
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256http:
>
> You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.commailto:xxxxx
>


Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256http:

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.commailto:xxxxx</mailto:xxxxx></http:></mailto:xxxxx></http:></mailto:xxxxx></http:></mailto:xxxxx></mailto:xxxxx></http:></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

Sorry, the device is completely hardwired with no firmware and I don’t know hw details. As for host side, I ended with 4 kB blocks because this page size and I had good results with it. But no problem since several 64 byte blocks (probably 4 and more) up to multiple pages. There was a problem when I tried big buffers (256 kB), data were lost at block boundary. And of course, using one block sized buffer was the worst case.

Buffer size as multiply of block size is necessary, otherwise it doesn’t work well or at all. The number of overlapped buffers isn’t limited if you program user mode part properly. The reasonable minimum is about 8, I guess we currently use 32. More is better if you have enough memory as at usual PC. It can be a problem at embedded devices with WinCE where a compromise is necessary.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]


From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of S. Drasnin[SMTP:xxxxx@msn.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, August 25, 2005 2:40 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] need practical throughput estimate for bulk endpoints

Thanks for the reply!

Did you (or one of your team members) program the usb device? If so, do you know how big the fifos were in the usb controller? Do you know how big the typical fifo is for bulk endpoints on the usb controller hardware? I was surprised at the 64 byte packet. I thought it might be 2 times the max packet size so that perhaps the control could ping pong between the two buffers and give the software time to empty one while the other was filling.

Also, how big were the buffers that you send down to the lowest level driver (which breaks them into 64 byte packets)? I would think that having the buffer you pass down being a multiple of 64 bytes (the low level packet size) would make the transfer rate faster.

thanks

----- Original Message -----
From: Michal Vodicka mailto:xxxxx
> To: Windows System Software Devs Interest List mailto:xxxxx
> Sent: Wednesday, August 24, 2005 3:49 PM
> Subject: RE: [ntdev] need practical throughput estimate for bulk endpoints
>
> 900 kiloBytes/sec is reasonable value which can be achieved without data lost. We have a “dumb” USB device which generates data stream which has to be captured by PC. Data rate can be controlled and I made some experiment several months before. If I remember correctly, I was able to capture 900 kB/sec with no problem (8 - 16 4 kB buffers always pending) and the maximal data rate was about 1.1 MB/sec but I don’t remember the exact value. Our device normally operates at ~800 kB/sec which is no problem to capture but overlapped IO is a must. We also use 64 bytes bulk endpoints and USB 1.1. I experimented at dual PIII/933 MHz; with faster machine results can be even better.
>
> BTW, units are case sensitive and if used correctly, there wouldn’t be a problem with understanding. kb != kB
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http:]
>
>
> > ----------
> > From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com mailto:xxxxx] on behalf of S. Drasnin[SMTP:xxxxx@msn.com]
> > Reply To: Windows System Software Devs Interest List
> > Sent: Thursday, August 25, 2005 12:33 AM
> > To: Windows System Software Devs Interest List
> > Subject: Re: [ntdev] need practical throughput estimate for bulk endpoints
> >
> > By the way, I did take look at the USB 1.1 spec and the usb.org forum. Here’s what I found, including some info that was confusing.
> > I’ve posted on the usb.org forum as well, but I’m hoping somebody on this newsgroup will also respond.>
> >
> > In section 5.0 of the USB 1.1 spec, the table 5-6 on page 48 shows the bulk transaction limits. For a 64 byte transfer, the number of useful (non-protocol, I think this means) data bytes/frame is 1216. With a frame = 1 ms, this would be 1.2 Mbytes/sec.
> >
> > (1) Since specs are theoretical, I went to the usb.org website and found a Q/A in which somebody asked what actual data rates look like on USB. I’ve pasted it in below. My question is if they meant 900 kilobits per second or 900 kilobytes per second?
> >
> > If the theoretical max is 12 Mbits-per-second, then 900 kbits/sec would be (900 kilo-bits-per-sec / 12000 kilo-bits-per-sec) * 100 = 9/120 * 100 = 7.5% of theoretical throughput.
> >
> > If the actual throughput is instead 900 K bytes per second, the actual throughput would be (900 K bytes per sec * 8 bits/byte) / 12000 kilo bytes per second * 100 = 60%, which makes more sense to me.
> >
> > (2) Can somebody give me an idea of what the actual throughput values they have seen for bulk endpoints? The host is a PC running Windows XP SP2 and the device has what I think is a 64 byte fifo. The packets being transferred are 64 bytes long. I do realize that there are also dependencies as to whether either the host or target is ready to receive/send data, etc, but I was hoping to get a typical value.
> >
> >
> >
> > <http:>
> > 1. What do actual data rates on USB look like?
> > A: USB’s actual throughput is a function of many variables. Typically, the most important ones are the target device’s ability to source or sink data, the bandwidth consumption of other devices on the bus, and the efficiency of the host’s USB software stack. In some cases, PCI latencies and processor loading can also be critical.
> > Assuming only the target endpoint consumes a significant amount of bus bandwidth-and both the target and the host are able to source or sink data as fast as USB can move it-the maximum attainable bandwidth is a function of the transfer type and signaling rate. These bandwidths are given in chapter 5 of the USB Specification. In practice, most hosts can reach the maximum isochronous and interrupt bandwidths with a single target endpoint. With bulk transfers, typical transfer rates are around 900kb/s to a single endpoint, increasing to near ideal transfer rates with multiple endpoints>
> >
> >
> > ----- Original Message -----
> > From: S. Drasnin <mailto:xxxxx>
> > To: Windows System Software Devs Interest List <mailto:xxxxx>
> > Sent: Wednesday, August 24, 2005 11:28 AM
> > Subject: [ntdev] need practical throughput estimate for bulk endpoints
> >
> > hi all:
> >
> > I need to get an idea of what is practically achievable for USB 1.1 bulk endpoint throughput.
> > Given a system that has one bulk in and one bulk out endpoints in use (no other endpoints in use), what is a practical rule of thumb of the throughput you’ll get?
> >
> > I realize there is some overhead as described in the 1.1 spec, and some over head for when either side is not ready, but I want to know what people really have been seeing? I think the controller we are using has a 64 byte fifo.
> >
> > It is unreasonable to achieve a 50% efficiency (50% of 12 Mbps)?
> >
> > It’s a hard pill for me to swallow when I hear somebody tell me that getting 16% efficiency is a reasonable value due to overhead.
> > What have you all been seeing? Even worse case would be good for me!
> >
> > thanks in advance
> >
> > —
> > Questions? First check the Kernel Driver FAQ at http:
> >
> > You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
> > To unsubscribe send a blank email to xxxxx@listsosr.com mailto:xxxxx>
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at http:
> >
> > You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
> > To unsubscribe send a blank email to xxxxx@listsosr.com mailto:xxxxx
> >
>
> —
> Questions? First check the Kernel Driver FAQ at http:
>
> You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
> To unsubscribe send a blank email to xxxxx@listsosr.com mailto:xxxxx
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
></mailto:xxxxx></http:></mailto:xxxxx></http:></mailto:xxxxx></http:></mailto:xxxxx></mailto:xxxxx></http:></mailto:xxxxx></http:></mailto:xxxxx></mailto:xxxxx>

S. Drasnin wrote:

hi all:

I need to get an idea of what is practically achievable for USB 1.1
bulk endpoint throughput.
Given a system that has one bulk in and one bulk out endpoints in use
(no other endpoints in use), what is a practical rule of thumb of the
throughput you’ll get?

I realize there is some overhead as described in the 1.1 spec, and
some over head for when either side is not ready, but I want to know
what people really have been seeing? I think the controller we are
using has a 64 byte fifo.

It is unreasonable to achieve a 50% efficiency (50% of 12 Mbps)?

It’s a hard pill for me to swallow when I hear somebody tell me that
getting 16% efficiency is a reasonable value due to overhead.
What have you all been seeing? Even worse case would be good for me!

We sustained 900 kB/s (7.2Mbps) for unloading the memory of a web cam
over a bulk pipe. The key is to have enough IRPs/URBs queued up so that
the host controller driver never runs dry. If you queue one read URB,
wait for it to come back, and then resubmit it, your performance will
suck. Queue up 3 or 4 URBs with a couple of k bytes in each, and you’ll
zoom.

We sustained 30 MB/s (240Mbps) on USB 2.0 bulk pipes overnight (15 in
and 15 out) with minimal CPU loading. We should have been able to beat
that, but we encountered a ceiling in our hardware, not in the bus.


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

30MBs on 2.0 seemed easy to get to in my testing as well. After that you
had to start playing games.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Thursday, August 25, 2005 5:29 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] need practical throughput estimate for bulk
endpoints

S. Drasnin wrote:

hi all:

I need to get an idea of what is practically achievable for USB 1.1
bulk endpoint throughput.
Given a system that has one bulk in and one bulk out endpoints in use
(no other endpoints in use), what is a practical rule of thumb of the
throughput you’ll get?

I realize there is some overhead as described in the 1.1 spec, and
some over head for when either side is not ready, but I want to know
what people really have been seeing? I think the controller we are
using has a 64 byte fifo.

It is unreasonable to achieve a 50% efficiency (50% of 12 Mbps)?

It’s a hard pill for me to swallow when I hear somebody tell me that
getting 16% efficiency is a reasonable value due to overhead.
What have you all been seeing? Even worse case would be good for me!

We sustained 900 kB/s (7.2Mbps) for unloading the memory of a web cam
over a bulk pipe. The key is to have enough IRPs/URBs queued up so that

the host controller driver never runs dry. If you queue one read URB,
wait for it to come back, and then resubmit it, your performance will
suck. Queue up 3 or 4 URBs with a couple of k bytes in each, and you’ll

zoom.

We sustained 30 MB/s (240Mbps) on USB 2.0 bulk pipes overnight (15 in
and 15 out) with minimal CPU loading. We should have been able to beat
that, but we encountered a ceiling in our hardware, not in the bus.


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


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

hi

thanks for the reply as well. Would you mind elaborating on the games you played to improve performance? You got me curious.

----- Original Message -----
From: Roddy, Markmailto:xxxxx
To: Windows System Software Devs Interest Listmailto:xxxxx
Sent: Thursday, August 25, 2005 3:30 PM
Subject: RE: [ntdev] need practical throughput estimate for bulk endpoints

30MBs on 2.0 seemed easy to get to in my testing as well. After that you
had to start playing games.

-----Original Message-----
From: xxxxx@lists.osr.commailto:xxxxx
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Thursday, August 25, 2005 5:29 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] need practical throughput estimate for bulk
endpoints

S. Drasnin wrote:

> hi all:
>
> I need to get an idea of what is practically achievable for USB 1.1
> bulk endpoint throughput.
> Given a system that has one bulk in and one bulk out endpoints in use
> (no other endpoints in use), what is a practical rule of thumb of the
> throughput you’ll get?
>
> I realize there is some overhead as described in the 1.1 spec, and
> some over head for when either side is not ready, but I want to know
> what people really have been seeing? I think the controller we are
> using has a 64 byte fifo.
>
> It is unreasonable to achieve a 50% efficiency (50% of 12 Mbps)?
>
> It’s a hard pill for me to swallow when I hear somebody tell me that
> getting 16% efficiency is a reasonable value due to overhead.
> What have you all been seeing? Even worse case would be good for me!

We sustained 900 kB/s (7.2Mbps) for unloading the memory of a web cam
over a bulk pipe. The key is to have enough IRPs/URBs queued up so that

the host controller driver never runs dry. If you queue one read URB,
wait for it to come back, and then resubmit it, your performance will
suck. Queue up 3 or 4 URBs with a couple of k bytes in each, and you’ll

zoom.

We sustained 30 MB/s (240Mbps) on USB 2.0 bulk pipes overnight (15 in
and 15 out) with minimal CPU loading. We should have been able to beat
that, but we encountered a ceiling in our hardware, not in the bus.


Tim Roberts, xxxxx@probo.commailto:xxxxx
Providenza & Boekelheide, Inc.


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256http:

You are currently subscribed to ntdev as: xxxxx@stratus.commailto:xxxxx
To unsubscribe send a blank email to xxxxx@lists.osr.commailto:xxxxx


Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256http:

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.commailto:xxxxx</mailto:xxxxx></http:></mailto:xxxxx></mailto:xxxxx></http:></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

No great secrets - this was a test device talking to a test application and
the ‘game’ was just to make sure that the application kept the device well
fed with pending requests. Everything asynch and multithreaded. Letting the
usbd subsystem do the chunking rather than doing it in the driver is a
massive win - but depending on your application it may not be appropriate.

=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of S. Drasnin
Sent: Thursday, August 25, 2005 10:02 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] need practical throughput estimate for bulk endpoints

hi

thanks for the reply as well. Would you mind elaborating on the games you
played to improve performance? You got me curious.

----- Original Message -----
From: Roddy, Mark mailto:xxxxx
To: Windows System Software Devs Interest mailto:xxxxx List

Sent: Thursday, August 25, 2005 3:30 PM
Subject: RE: [ntdev] need practical throughput estimate for bulk endpoints

30MBs on 2.0 seemed easy to get to in my testing as well. After that you
had to start playing games.

-----Original Message-----
From: xxxxx@listsosr.com
mailto:xxxxx
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Thursday, August 25, 2005 5:29 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] need practical throughput estimate for bulk
endpoints

S. Drasnin wrote:

> hi all:
>
> I need to get an idea of what is practically achievable for USB 1.1
> bulk endpoint throughput.
> Given a system that has one bulk in and one bulk out endpoints in use
> (no other endpoints in use), what is a practical rule of thumb of the
> throughput you’ll get?
>
> I realize there is some overhead as described in the 1.1 spec, and
> some over head for when either side is not ready, but I want to know
> what people really have been seeing? I think the controller we are
> using has a 64 byte fifo.
>
> It is unreasonable to achieve a 50% efficiency (50% of 12 Mbps)?
>
> It’s a hard pill for me to swallow when I hear somebody tell me that
> getting 16% efficiency is a reasonable value due to overhead.
> What have you all been seeing? Even worse case would be good for me!

We sustained 900 kB/s (7.2Mbps) for unloading the memory of a web cam
over a bulk pipe. The key is to have enough IRPs/URBs queued up so that

the host controller driver never runs dry. If you queue one read URB,
wait for it to come back, and then resubmit it, your performance will
suck. Queue up 3 or 4 URBs with a couple of k bytes in each, and you’ll

zoom.

We sustained 30 MB/s (240Mbps) on USB 2.0 bulk pipes overnight (15 in
and 15 out) with minimal CPU loading. We should have been able to beat
that, but we encountered a ceiling in our hardware, not in the bus.


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


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@listsosr.com
mailto:xxxxx


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@listsosr.com
mailto:xxxxx


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>