Max. transfer speed of a bulk endpoint on a full-speed connection

[compuphase]

Hello everyone,

I have a feeling that I am overlooking something in my calculation, so I am hoping someone can clarify.

My microcontroller supports full-speed. For a bulk endpoint, that means: max. packet size of 64 bytes. Frames are on a 1 millisecond interval, so there are 1000 frames per second, carrying (max.) 64000 bytes to/from that bulk endpoint. That gives me a transfer speed of 512 kbits/s, or 0.5 Mbits/s.

Is this correct?

The transfer speed of 0.5 Mbits/s is roughly what I am measuring. If I want to increase speed, where should I start?

Thanks in advance for any help.
Regards,
Thiadmer Riemersma

[compuphase]

Answering my own question: yes, I overlooked something. On page 76 of USB Complete, it is explained that a frame can hold up to 19 bulk packets (for the same endpoint).

[Barry Twycross]

19 packets per frame is the theoretical max that a full speed controller can support. Not all controllers can manage this. It also depends on the controller, roughly how complex the controller is and how many accesses to memory it needs to make and how fast the memory is. Most controllers are PCI, so the PCI latency is important in how fast memory appears to the controller.

First was UHCI. This uses simple memory access and the controllers are relatively simple. Most UHCI can manage 18-19 packets per frame.

Next was OCHI, these are considerably more complex and require more memory accesses. They can manage something like 15-17 packets a frame.

There was a bug in an early OHCI controller, and the workaround for the bug in effect slowed down the controller. So a popular early OCHI implementation would do 14-16 packets a frame. This shipped in many systems.

A later implementation was just plain bad, and could only manage 14-16 packets a frame, but as it was as fast as the existing implementation (when slowed down with the workaround), no one noticed. This was also popular and shipped in many systems.

When this slow implementation was incorporated as the companion controller of an EHCI chip, no one took much notice of how slow it was and one implementation put three PCI bridges between it and memory, and you're lucky to get 12 packets a frame out of one of those.

With USB 3 there was a change in the controller implementation, they use XHCI. XHCI controls full speed (as well as low, high and super), and uses a very different architecture so it doesn't depend on memory latency anymore. I think XHCI controllers tend to the higher end, 17-19 packets a frame.

[Barry Twycross]

The transfer speed of 0.5 Mbits/s is roughly what I am measuring. If I want to increase speed, where should I start?

The usual way to increase throughput is to make larger requests and to make multiple concurrent requests.

There is some latency starting and finishing a request, so if you request small amounts of data, like 64 bytes at a time, the latency overwhelms the bus transfer speed and the system spends all its time making and completing requests, not transferring data. Asking the system for multiple ks or Ms of data at once will usually speed things up a lot.

If that's not fast enough, you may need to investigate asynchronous transactions and make multiple concurrent (large) transactions at once. Most architectures are such that a request ends up as a transfer descriptor queued on a controller. When the controller finishes one descriptor, it can start on another one without a pause, if one is available. You can make sure they're available by queueing them up ahead of time, which takes asynchronous requests.

[Bret]

In addition to what Barry stated, there may also be other factors that determine how fast data can be transferred.  For example, if the bus has any other devices attached to it, they will be competing with your device for the bus bandwidth.  And, if those other devices use isochronous or interrupt transfers, the packets associated with those devices will receive higher priority than the bulk packets and effectively slow the transfer rate, or at least increase the latency of the data transfer, for your device.

There may also be additional overhead associated with your device like there is with Mass Storage Devices (MSD).  Transferring data to/from a MSD requires a minimum of three sequential bulk transactions to traverse the bus, two containing "overhead" and only one containing actual data.

The theoretical data throughput and the actual data throughput may be very different from each other depending on a lot of specific implementation details.

[compuphase]

Barry and Brett, thanks your your clarifications.

The device implements the CDC/ACM class, and on the host I am using the standard Windows driver (usbser). The usbser driver may be part of the problem. I will investigate a bit further.

[TonyZ]

Hello,

To continue on this thread, I am also trying to maximize throughput on a bulk endpoint. However, I am currently only able to achieve about 250K bits/sec.
It is a full speed link, so shouldn't the theoretical max be close to 12M bits/sec.? If so, I am way off, like 48 times slower than the max.

I have adopted Jan's C# WinUsb_cs example to work with my Silicon Labs SiM3U167 usb microcontroller embedded hardware. I am using MS Visual Studio Express with 32-bit Windows 7.

Reading the previous posts, I see one problem is that I am requesting one 64 byte packet from the device at a time, and once it arrives at the host, I then request another packet. But it appears that the functions that Jan provides, like RequestToReceiveDataViaBulkTransfer(...) are limited to 64 bytes at a time. So it appears that I cannot request more than 64 bytes per function call.

To increase my transfer rate, should I simply request more 64 byte packets at a time? Or is there a better way.

Thanks!
Tony

[Jan Axelson]

Yes, a transfer can request more than 64 bytes.