USB Isochronous

NTDEV
1

Hi,

I am developing a driver for USB based microcontroller. The microcontroller reads A/D data from the A/D chip and send it through the USB. There is only one problem with the USB. My data packets are getting lost too much. Lets suppose I am sending 10 packets each 1020 bytes. On my driver side, using the continuous reader, I am hardly getting 3 packets each 1020 bytes only. I am losing not one or two packets but more than half of the packets.

Microcontroller: - Coldfire MCF52259
USB Support: - Full Speed

Isochronous Endpoint

0 bLength 07h
1 bDescriptorType 05h Endpoint
2 bEndpointAddress 81h 1 In
3 bmAttributes 01h Isochronous, No Sync, Data
1..0: Transfer Type ......01 Isochronous
3..2: Sync Type ....00.. No Sync
5..4: Usage Type ..00.... Data
7..6: Reserved 00......
4 wMaxPacketSize 03FFh 1023 bytes
6 bInterval 03h 4 ms

Also, my driver is written in WDM rather than in KDMF.

Regards.

2

xxxxx@prescott-instruments.com wrote:

I am developing a driver for USB based microcontroller. The microcontroller reads A/D data from the A/D chip and send it through the USB. There is only one problem with the USB. My data packets are getting lost too much. Lets suppose I am sending 10 packets each 1020 bytes. On my driver side, using the continuous reader, I am hardly getting 3 packets each 1020 bytes only. I am losing not one or two packets but more than half of the packets.

At what rate are they generated? How much buffering do you have in your
device? Your endpoint is set up to transfer 1023 bytes every 4 ms. So,
if you generate all 10 packets instantly, you had better have at least
10k of buffering on the device.

When you create your URBs, how many packets per URB are you sending, and
how many URBs do you submit at once?

When you say “continuous reader”, do you mean a continuous reader of
your own invention? There’s no standard continuous reader that works
with isochronous pipes.

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

3

Use bulk pipe. Less pain, and the delivery is guaranteed.

And the bulk pipe will give you more throughput, in case you need it. Althouthg you don’t need it now.

4

Hi Tim,

Thanks for the reply.

I am using 10 packets per URB and 5 URBs are submitted at once. Each packet contains a buffer of 1023 bytes.

Yes, the continuous reader is my own implementation.

Also, I set the TransferFlags in the URB to USBD_START_ISO_TRANSFER_ASAP. I did not mention any frame number. Is that alright.

Regards.

5

>Use bulk pipe. Less pain, and the delivery is guaranteed<

I think this is probably good advice. Isochronous should be the correct solution for media delivery at guaranteed speed at the cost of no guarantee of arrival of packets, but always seems to be (a) flakier to implement, (b) lower absolute bandwidth than bulk, (c) higher latency in practice, (d) less user mode support. I suspect that it is good in principle but not suited to a non real time OS like Windows. After all, if Windows can’t deliver guaranteed throughput what is the point of guaraneteed throughput on the bus.

Instead using bulk pipes with a request to the user not to use the same bus for big bulk devices probably makes for a better overall solutions. And if the data falls behind, it is more likely to be Windows being busy than the USB pipe.

OTOH as part of a realtime system, isochronous would make sense…

Mike
----- Original Message -----
From: xxxxx@broadcom.com
To: Windows System Software Devs Interest List
Sent: Tuesday, June 25, 2013 7:40 PM
Subject: RE:[ntdev] USB Isochronous

Use bulk pipe. Less pain, and the delivery is guaranteed.

And the bulk pipe will give you more throughput, in case you need it. Althouthg you don’t need it now.

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

Hi Mike,

Thanks for the reply.

For bulk transfer, the maximum bytes I could send out will be 64 in single packet.

Looking on the internet, the speed for bulk transfer on full speed device is 1.2 M Bytes/sec which is higher than isochronous transfer (1.023 M Bytes/sec) and the bulk transfer is guaranteed. Is this correct?

Regards.

7

Sorry, don’t have the specs to hand. usb.org should have all the specification documents, which are better than second hand knowledge. Full speed should be covered in the USB2.0 spec http://www.usb.org/developers/docs/usb_20_040413.zip

But throughput on bulk is usually signifcantly higher, afair only 20% of the USB2 bus bandwidth is available to be reserved for isochronous…

Bulk is guaranteed delivery but not guaranteed bandwidth, but if nothing else is using the bus you can use the whole bandwidth.

Mike
----- Original Message -----
From: xxxxx@prescott-instruments.com
To: Windows System Software Devs Interest List
Sent: Wednesday, June 26, 2013 11:10 AM
Subject: RE:[ntdev] USB Isochronous

Hi Mike,

Thanks for the reply.

For bulk transfer, the maximum bytes I could send out will be 64 in single packet.

Looking on the internet, the speed for bulk transfer on full speed device is 1.2 M Bytes/sec which is higher than isochronous transfer (1.023 M Bytes/sec) and the bulk transfer is guaranteed. Is this correct?

Regards.

NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

8

xxxxx@prescott-instruments.com wrote:

For bulk transfer, the maximum bytes I could send out will be 64 in single packet.

That’s irrelevant. Unlike isochronous, bulk transfers will fill out the
entire frame. As long as you have requests waiting, the host controller
driver will pack as many of them into a single frame as will fit.

Looking on the internet, the speed for bulk transfer on full speed device is 1.2 M Bytes/sec which is higher than isochronous transfer (1.023 M Bytes/sec) and the bulk transfer is guaranteed. Is this correct?

I’m assuming total bandwidth is not be an issue for you. Your
descriptor has the interval set to 4ms, so you are only using 256k
bytes/sec.

Bulk transfers get retried if there is a transmission error.
Isochronous transfers do not – erroneous packets are simply dropped.

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

9

Mike Kemp wrote:

Sorry, don’t have the specs to hand. usb.org should have all the
specification documents, which are better than second hand knowledge.
Full speed should be covered in the USB2.0 spec
http://www.usb.org/developers/docs/usb_20_040413.zip

But throughput on bulk is usually signifcantly higher, afair only 20%
of the USB2 bus bandwidth is available to be reserved for isochronous…

No, that’s backwards. 10% of the bandwidth is reserved for control pipe
usage. All of the rest can be assigned to scheduled pipes (isochronous
and interrupt).

Plus, the OP is using full speed, which is USB 1. In that case, 1023
out of the roughly 1200 available bytes per frame can be isochronous.

At full speed, a maximum isochronous pipe bandwidth is within 15% or 20%
of a maximum bulk pipe. At high speed, the difference is much more
significant; a maximum isochronous pipe gets less than half of a maximum
bulk pipe.

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

10

Hi, Razzaq,

aFTER reading the stairs above.

I was wonder:

  1. why you select FULL speed device, in this 5G USB3.0 age, or 10G is near.

  2. Anyway, your ISO data 4ms with 1023/1020 bytes, is a very slow speed.
    Have you prepare enough buffer before windows drive polling the ISO in pipe?

I guess is reason lay on:
you did not prepare enough buffer AHEAD of Windows ISO in pipe polling.

How do allocate the EP buffer in device side?

11

workingmailing@163.com wrote:

aFTER reading the stairs above.

I was wonder:

  1. why you select FULL speed device, in this 5G USB3.0 age, or 10G is near.

Because 5 GHz clocks require more expensive chips and more expensive
board layouts. If you don’t need the extra bandwidth, why pay for it?

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