How do USB 2.0 devices attain high throuput?

I am contemplating a design. The Cypress FX2 docs state that USB 2.0 buffers 
can be up to 512 bytes for bulk transfers. If USB 2.0 is only services every 
125 uS then how do drives and other devices get closer to the ~60mB through 
put?  Or even the 25mB average of drives?

Thanks

n 

nappy wrote:
> I am contemplating a design. The Cypress FX2 docs state that USB 2.0 buffers
> can be up to 512 bytes for bulk transfers. If USB 2.0 is only services every
> 125 uS then how do drives and other devices get closer to the ~60mB through
> put?  Or even the 25mB average of drives?

The actual 'service' frequency can be much higher. The 125 us you are
referring to is the micro frame size. Some endpoints, like interrupts,
are only polled once per micro frame, but bulk data can be transferred
in a burst. Typically, when the device responds with a full sized data
packet (512) bytes, the host will immediately ask for the next one. Of
course, this also depends on the driver, which should try to read large
blocks at once. If the device responds with a smaller packet, this is
usually interpreted as the end of the transfer, and the host could stop
polling until the driver has set up the next request.

When sending data to a device, if the device responds with NYET, some
hosts will also introduce a delay before each PING. If you want high
throughput, it's important to avoid the NYET responses as much as
possible. How you do that, depends on the device.

Using 64KB bulk requests, I can read more than 300 Mbit/sec from my USB
2.0 device (not Cypress based, btw).

"Artenz" <usenet+5@ladybug.xs4all.nl> wrote in message 
news:1140867952.538088.255540@p10g2000cwp.googlegroups.com...
> nappy wrote:
>> I am contemplating a design. The Cypress FX2 docs state that USB 2.0 
>> buffers
>> can be up to 512 bytes for bulk transfers. If USB 2.0 is only services 
>> every
>> 125 uS then how do drives and other devices get closer to the ~60mB 
>> through
>> put?  Or even the 25mB average of drives?
>
> The actual 'service' frequency can be much higher. The 125 us you are
> referring to is the micro frame size. Some endpoints, like interrupts,
> are only polled once per micro frame, but bulk data can be transferred
> in a burst. Typically, when the device responds with a full sized data
> packet (512) bytes, the host will immediately ask for the next one. Of
> course, this also depends on the driver, which should try to read large
> blocks at once. If the device responds with a smaller packet, this is
> usually interpreted as the end of the transfer, and the host could stop
> polling until the driver has set up the next request.
>
> When sending data to a device, if the device responds with NYET, some
> hosts will also introduce a delay before each PING. If you want high
> throughput, it's important to avoid the NYET responses as much as
> possible. How you do that, depends on the device.
>
> Using 64KB bulk requests, I can read more than 300 Mbit/sec from my USB
> 2.0 device (not Cypress based, btw).
>

Thank you very much. .I will revisit the spec. Good info! 

nappy <gospam@yourself.com> wrote:
> I am contemplating a design. The Cypress FX2 docs state that USB 2.0
> buffers can be up to 512 bytes for bulk transfers. If USB 2.0 is only
> services every 125 uS then how do drives and other devices get closer to
> the ~60mB through put?  Or even the 25mB average of drives?

The 125uS timebase allows you to do 13 of 512 byte bulk transfers in each frame.
This allows you to transfer 5324800 bytes per seconds which is approximately
50.7 MBytes/s if you are working in base 2 or 53.2 MBytes if you are in base
10.

Actually getting that data rate depends on the endpoint not issuing any NAKs
during the microframe. If the host controller sees a NAK it has to stop
sending data.

If you need timing guarentees then you'd need to do Isochronous transfers
and the limit is 2 of 3072 byte transfers ie about 46 Mbytes/s base 2

In practice actually achieving either of these maxima usually requires that
your device is the only thing on the bus except for the host controller.

Download and look at chapter 5, particularly 5.4, 5.6 and 5.8 of usb_20.pdf in
the zipfile from

http://www.usb.org/developers/docs/usb_20_02212005.zip

Personally I prefer IEEE1394 which looks inferior if you look at marketing
blurb but is better in practice.

-p
-- 
 "What goes up must come down, ask any system administrator"
--------------------------------------------------------------------

good stuff .. Thank you Paul.


"Paul Gotch" <paulg@at-cantab-dot.net> wrote in message 
news:Y3B*5Hdar@news.chiark.greenend.org.uk...
> nappy <gospam@yourself.com> wrote:
>> I am contemplating a design. The Cypress FX2 docs state that USB 2.0
>> buffers can be up to 512 bytes for bulk transfers. If USB 2.0 is only
>> services every 125 uS then how do drives and other devices get closer to
>> the ~60mB through put?  Or even the 25mB average of drives?
>
> The 125uS timebase allows you to do 13 of 512 byte bulk transfers in each 
> frame.
> This allows you to transfer 5324800 bytes per seconds which is 
> approximately
> 50.7 MBytes/s if you are working in base 2 or 53.2 MBytes if you are in 
> base
> 10.
>
> Actually getting that data rate depends on the endpoint not issuing any 
> NAKs
> during the microframe. If the host controller sees a NAK it has to stop
> sending data.
>
> If you need timing guarentees then you'd need to do Isochronous transfers
> and the limit is 2 of 3072 byte transfers ie about 46 Mbytes/s base 2
>
> In practice actually achieving either of these maxima usually requires 
> that
> your device is the only thing on the bus except for the host controller.
>
> Download and look at chapter 5, particularly 5.4, 5.6 and 5.8 of 
> usb_20.pdf in
> the zipfile from
>
> http://www.usb.org/developers/docs/usb_20_02212005.zip
>
> Personally I prefer IEEE1394 which looks inferior if you look at marketing
> blurb but is better in practice.
>
> -p
> -- 
> "What goes up must come down, ask any system administrator"
> --------------------------------------------------------------------