usb 2.0 transfer speed

NTDEV
1

Hi,

is there a way to find out how “strict” Windows (XP/7) is with regards to sending out
USB 2.0 packets. I.e. I need to transfer 256k of data within 512 bytes of USB packets,
what can I assume about the time between each and every packet? Is there any?
Can I with any API call to enforce some?
Thanks,

2

What type is the endoint? In general, the answer is that there are no such strict timing or packet scheduling guarantees. What problem are you trying to solve?

d

debt from my phone

From: xxxxx@chello.hu
Sent: 12/12/2011 7:38 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] usb 2.0 transfer speed

Hi,

is there a way to find out how “strict” Windows (XP/7) is with regards to sending out
USB 2.0 packets. I.e. I need to transfer 256k of data within 512 bytes of USB packets,
what can I assume about the time between each and every packet? Is there any?
Can I with any API call to enforce some?
Thanks,

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

3

xxxxx@chello.hu wrote:

is there a way to find out how “strict” Windows (XP/7) is with regards to sending out
USB 2.0 packets. I.e. I need to transfer 256k of data within 512 bytes of USB packets,
what can I assume about the time between each and every packet? Is there any?
Can I with any API call to enforce some?

Assuming you are talking about a bulk pipe, the transfers will go as
quickly as possible. If there is nothing else on the USB bus, your
packets will be packed together tightly, one right after the other.
Your 256k bytes will transfer in about 60 milliseconds.

If your device can’t handle that, then your device sends a NAK, and the
host controller will retry the request until it succeeds. If you need
periodic transfers (for example, one packet per millisecond), then you
need to use an interrupt pipe.

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

4

Hi,

yes currently the pipes are configured as bulk. The complete setup consists of 3 items:
a.) the PC, sends data to an embedded AVR32 USB2.0 device
b.) the AVR32, which acts as a firmware programmer practically
c.) the target device that is connected to the AVR32

Practically the data streamed from the PC to the taqrget device through the AVR32. The data
is transferred in a kind-of-i2c format from the AVR32 to the target device. The target device
expects a constant data rate during programming. Right now there are cases when the firmware
process stops. What I can see is that the complete 256k is NAKed by the target device.
I’ve optimized the transfer code in the AVR32 as much as I could, when I scoped the transfer
I could see perfect waveforms sent to the target device. So right now I am looking for the PC driver
code to make sure that all the packets in the 256k is sent as fast as possible to the AVR32, and then
to the target device (practically the AVR32 reads the USB constantly and streams the 512 byte
packets to the target device as fast as possible - yeah forgot to mention that I’m in control of
the AVR32 firmware, too).
So I’m looking for a way to maximize the throughput from the PC to the AVR32.
Any idea in that direction?

5

Make sure you have more than one urb pending in the pipe to transfer to the above. That way when the first completes, the next one is next in line with minimal wait

d

debt from my phone

From: xxxxx@chello.hu
Sent: 12/12/2011 11:25 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] usb 2.0 transfer speed

Hi,

yes currently the pipes are configured as bulk. The complete setup consists of 3 items:
a.) the PC, sends data to an embedded AVR32 USB2.0 device
b.) the AVR32, which acts as a firmware programmer practically
c.) the target device that is connected to the AVR32

Practically the data streamed from the PC to the taqrget device through the AVR32. The data
is transferred in a kind-of-i2c format from the AVR32 to the target device. The target device
expects a constant data rate during programming. Right now there are cases when the firmware
process stops. What I can see is that the complete 256k is NAKed by the target device.
I’ve optimized the transfer code in the AVR32 as much as I could, when I scoped the transfer
I could see perfect waveforms sent to the target device. So right now I am looking for the PC driver
code to make sure that all the packets in the 256k is sent as fast as possible to the AVR32, and then
to the target device (practically the AVR32 reads the USB constantly and streams the 512 byte
packets to the target device as fast as possible - yeah forgot to mention that I’m in control of
the AVR32 firmware, too).
So I’m looking for a way to maximize the throughput from the PC to the AVR32.
Any idea in that direction?

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

6

If you’re looking for a consistent data rate across the USB, you want isochronous transfers, not bulk. Bulk does not guarantee a bandwidth, whereas isochronous does.

  1. Have you considered you may be going “too fast” for your target device and it just can’t handle the data?
  2. Have you connected a USB bus analyzer and looked at the timing diagrams?
  3. You said it was USB 2.0, but you did not mention whether it was full speed (12 Mbps) or High Speed (480 Mbps). Saying “USB 2.0” doesn’t tell the speed, just the protocol standard.
  4. Do you have any hubs in between? If the device is high speed, it probably would not matter. If it is full speed, the “transaction translator” inside the hub does some wierd things to match up the speeds.
  5. Have you checked the max transfer size for the target device? If you exceed that, you will get NAKs all over the place.

Greg

— xxxxx@chello.hu wrote:

From: xxxxx@chello.hu
To: “Windows System Software Devs Interest List”
Subject: RE:[ntdev] usb 2.0 transfer speed
Date: Mon, 12 Dec 2011 14:24:47 -0500 (EST)

Hi,

yes currently the pipes are configured as bulk. The complete setup consists of 3 items:
a.) the PC, sends data to an embedded AVR32 USB2.0 device
b.) the AVR32, which acts as a firmware programmer practically
c.) the target device that is connected to the AVR32

Practically the data streamed from the PC to the taqrget device through the AVR32. The data
is transferred in a kind-of-i2c format from the AVR32 to the target device. The target device
expects a constant data rate during programming. Right now there are cases when the firmware
process stops. What I can see is that the complete 256k is NAKed by the target device.
I’ve optimized the transfer code in the AVR32 as much as I could, when I scoped the transfer
I could see perfect waveforms sent to the target device. So right now I am looking for the PC driver
code to make sure that all the packets in the 256k is sent as fast as possible to the AVR32, and then
to the target device (practically the AVR32 reads the USB constantly and streams the 512 byte
packets to the target device as fast as possible - yeah forgot to mention that I’m in control of
the AVR32 firmware, too).
So I’m looking for a way to maximize the throughput from the PC to the AVR32.
Any idea in that direction?

—
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

7

xxxxx@chello.hu wrote:

Practically the data streamed from the PC to the taqrget device through the AVR32. The data
is transferred in a kind-of-i2c format from the AVR32 to the target device. The target device
expects a constant data rate during programming. Right now there are cases when the firmware
process stops. What I can see is that the complete 256k is NAKed by the target device.

How much memory do you have in the AVR32? If you have enough, you could
suck the whole thing into memory, and then you’d be in complete
control. How fast can the target device suck the data? USB is blowing
at 45 MB/s; in my experience, most chips can’t be programmed at nearly
that rate. I seriously doubt that the PC is your bottleneck.

…(practically the AVR32 reads the USB constantly and streams the 512 byte
packets to the target device as fast as possible - yeah forgot to mention that I’m in control of
the AVR32 firmware, too).

Does the AVR32 allow you to receive another USB packet at the same time
you’re doling out that last one? If so, it’s really hard for me to
believe that you are getting behind.

So I’m looking for a way to maximize the throughput from the PC to the AVR32.
Any idea in that direction?

Are you sending the entire 256k chunk as a single URB? You can’t do any
better than that. The host controller will chop it into packets and
pack them as tightly as it can in the available bandwidth. Now, if
you’re trying to do Skype with your web camera while streaming 24-bit
audio data to your USB speakers at the same time, then that’s going to
limit the bulk time.

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

8

Yes, it is a usb 2.0 high speed device. No hubs inbetween.
The transfer is done my own kmdf driver, one urb.
The target device could handle even faster transfer rate, i scoped an
(way faster) fpga implementation that delivered the stream almost
twice as fast.
The avr32 has only 65k consecutive ram so there is no place to read
the complete 65k. Right now i am sending each and every usb 512 byte
packet to the target device without buffering more in the avr32.
The reason is that i thought that waiting for multiple 512bytes
packets at obe time would increase the time gap between the
I2c-alike transfer blocks sent to the target device.
Actually i am not aware of the avr32 being able to wait for a second
packet while processing the first.
And no, max transfer size is not violated for sure.

9

xxxxx@chello.hu wrote:

The target device could handle even faster transfer rate, i scoped an
(way faster) fpga implementation that delivered the stream almost
twice as fast.
…
The reason is that i thought that waiting for multiple 512bytes
packets at obe time would increase the time gap between the
I2c-alike transfer blocks sent to the target device.

I’m confused. I2C typically runs at 400 kHz, although some chips
support 1 MHz. That’s a serial connection, so even at 1 MHz, you’re
only pumping about 100 kB/sec. There is no way in this universe that an
I2C connection could ever outrun a bulk pipe. No way. What timing are
you seeing, exactly?

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