usb 2.0 isochronous transfers not working on a usb 3.0 host controller

NTDEV
1

Has anybody experienced any problems with usb 2.0 isochronous transfers using a laptop with usb 3.0?

We have a usb 2.0 device with a kernel mode device driver that uses isochronous transfers. The isochronous transfers have been working fine on a variety of laptops for the last 7 years. We?ve recently updated the driver to support Windows 7 (32 and 64 bit), and it?s running with the latest version of the WDK (7600). It?s working fine on a variety of XP, Vista, and Windows 7 systems that have usb 2.0 ports.

We have two test laptops that have usb 3.0 host controllers. Both are running 64 bit Windows 7. One is a Sony Viao, which works perfectly. The other is a Lenovo, and on this machine, in my kernel mode driver, I find that I?m ?losing? isochronous data. I?m examining the urbs that contain the isochronous data?they are not showing any errors, but some of the packets I?m expecting are missing.

If I look at the data on a usb analyzer, I see that all the data is in fact being sent across the usb bus. However, the timing of the packets is a little bit off. I should be seeing packets every 125uSec, but around 10% of the time, the interval between microframes is larger than this?falling between 126uSec and around 180uSec. I suspect that this is causing the usb 3.0 host controller to drop some of the data, due to it being an isochronous pipe.

I should also mention that this same laptop also has usb 2.0 ports. If I run our device on those ports, it works perfectly, so the problem seems to be with the usb 3.0 host controller. If I look at the usb analyzer, I see that the timing of the isochronous transfers using the usb 2.0 port is perfect?all the microframes are within 1uSec of being 125uSec apart.

Regarding the isochronous transfers, we are sending either 1 or 2 1024 byte packets of data every microframe. We transfer 150 packets this way, then there is a brief period of empty packets (15 or so microframes), before the next block of 150 packets is sent.

I?ve update the usb 3.0 host controllers to use the latest version of drivers (Renesas version 2.0.34.0). This happens to be the same version that is running on the Sony Vaio, which works fine.

Has anybody else experienced problems with isochronous transfers from a usb 2.0 device using a usb 3.0 host controller?

Thanks,
Jeff

2

Have you asked renesas? It is their stack’s issue.

d

debt from my phone

-----Original Message-----
From: xxxxx@gnotometrics.com
Sent: Tuesday, April 12, 2011 7:19 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] usb 2.0 isochronous transfers not working on a usb 3.0 host controller

Has anybody experienced any problems with usb 2.0 isochronous transfers using a laptop with usb 3.0?

We have a usb 2.0 device with a kernel mode device driver that uses isochronous transfers. The isochronous transfers have been working fine on a variety of laptops for the last 7 years. We?ve recently updated the driver to support Windows 7 (32 and 64 bit), and it?s running with the latest version of the WDK (7600). It?s working fine on a variety of XP, Vista, and Windows 7 systems that have usb 2.0 ports.

We have two test laptops that have usb 3.0 host controllers. Both are running 64 bit Windows 7. One is a Sony Viao, which works perfectly. The other is a Lenovo, and on this machine, in my kernel mode driver, I find that I?m ?losing? isochronous data. I?m examining the urbs that contain the isochronous data?they are not showing any errors, but some of the packets I?m expecting are missing.

If I look at the data on a usb analyzer, I see that all the data is in fact being sent across the usb bus. However, the timing of the packets is a little bit off. I should be seeing packets every 125uSec, but around 10% of the time, the interval between microframes is larger than this?falling between 126uSec and around 180uSec. I suspect that this is causing the usb 3.0 host controller to drop some of the data, due to it being an isochronous pipe.

I should also mention that this same laptop also has usb 2.0 ports. If I run our device on those ports, it works perfectly, so the problem seems to be with the usb 3.0 host controller. If I look at the usb analyzer, I see that the timing of the isochronous transfers using the usb 2.0 port is perfect?all the microframes are within 1uSec of being 125uSec apart.

Regarding the isochronous transfers, we are sending either 1 or 2 1024 byte packets of data every microframe. We transfer 150 packets this way, then there is a brief period of empty packets (15 or so microframes), before the next block of 150 packets is sent.

I?ve update the usb 3.0 host controllers to use the latest version of drivers (Renesas version 2.0.34.0). This happens to be the same version that is running on the Sony Vaio, which works fine.

Has anybody else experienced problems with isochronous transfers from a usb 2.0 device using a usb 3.0 host controller?

Thanks,
Jeff

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

Hi Jeff,

Has anybody experienced any problems with usb 2.0 isochronous transfers using a laptop with usb 3.0?

yes. I can confirm that a number of USB 3.0 chips / drivers seem to have significant problems with USB 2.0 isochronous transfers. I am experiencing that my OUT transfers do ‘hang’ in the hub driver after some milliseconds.

We have a usb 2.0 device with a kernel mode device driver that uses isochronous transfers. The isochronous transfers have been working fine on a variety of laptops for the last 7 years. We?ve recently updated the driver to support Windows 7 (32 and 64 bit), and it?s running with the latest version of the WDK (7600). It?s working fine on a variety of XP, Vista, and Windows 7 systems that have usb 2.0 ports.

We have two test laptops that have usb 3.0 host controllers. Both are running 64 bit Windows 7. One is a Sony Viao, which works perfectly. The other is a Lenovo, and on this machine, in my kernel mode driver, I find that I?m ?losing? isochronous data. I?m examining the urbs that contain the isochronous data?they are not showing any errors, but some of the packets I?m expecting are missing.

If I look at the data on a usb analyzer, I see that all the data is in fact being sent across the usb bus. However, the timing of the packets is a little bit off. I should be seeing packets every 125uSec, but around 10% of the time, the interval between microframes is larger than this?falling between 126uSec and around 180uSec. I suspect that this is causing the usb 3.0 host controller to drop some of the data, due to it being an isochronous pipe.

I should also mention that this same laptop also has usb 2.0 ports. If I run our device on those ports, it works perfectly, so the problem seems to be with the usb 3.0 host controller. If I look at the usb analyzer, I see that the timing of the isochronous transfers using the usb 2.0 port is perfect?all the microframes are within 1uSec of being 125uSec apart.

Regarding the isochronous transfers, we are sending either 1 or 2 1024 byte packets of data every microframe. We transfer 150 packets this way, then there is a brief period of empty packets (15 or so microframes), before the next block of 150 packets is sent.

I?ve update the usb 3.0 host controllers to use the latest version of drivers (Renesas version 2.0.34.0). This happens to be the same version that is running on the Sony Vaio, which works fine.

The problem seems to be related to the USB 3.0 chip. Older ones do cause problems, newer ones seem to work.

Has anybody else experienced problems with isochronous transfers from a usb 2.0 device using a usb 3.0 host controller?

I’ve already tried to contact a number of USB 3.0 PCI-e card vendors and also the tech support at Renesas, but without any success. The PCI-e card vendors do all use the generic Renesas drivers, and Renesas tech support refuses to give any support on 3rd party OEM designs.

Can you please keep me updated on you findings?

Thanks,
Jeff

Thanks,
Franz

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

4

Hi Doron,

Have you asked renesas? It is their stack’s issue.

my tries to find someone responsible at Renesas failed so far.

Do you have any contacts there?

d

Thanks,
Franz

debt from my phone

-----Original Message-----
From: xxxxx@gnotometrics.com
Sent: Tuesday, April 12, 2011 7:19 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] usb 2.0 isochronous transfers not working on a usb 3.0 host controller

Has anybody experienced any problems with usb 2.0 isochronous transfers using a laptop with usb 3.0?

We have a usb 2.0 device with a kernel mode device driver that uses isochronous transfers. The isochronous transfers have been working fine on a variety of laptops for the last 7 years. We?ve recently updated the driver to support Windows 7 (32 and 64 bit), and it?s running with the latest version of the WDK (7600). It?s working fine on a variety of XP, Vista, and Windows 7 systems that have usb 2.0 ports.

We have two test laptops that have usb 3.0 host controllers. Both are running 64 bit Windows 7. One is a Sony Viao, which works perfectly. The other is a Lenovo, and on this machine, in my kernel mode driver, I find that I?m ?losing? isochronous data. I?m examining the urbs that contain the isochronous data?they are not showing any errors, but some of the packets I?m expecting are missing.

If I look at the data on a usb analyzer, I see that all the data is in fact being sent across the usb bus. However, the timing of the packets is a little bit off. I should be seeing packets every 125uSec, but around 10% of the time, the interval between microframes is larger than this?falling between 126uSec and around 180uSec. I suspect that this is causing the usb 3.0 host controller to drop some of the data, due to it being an isochronous pipe.

I should also mention that this same laptop also has usb 2.0 ports. If I run our device on those ports, it works perfectly, so the problem seems to be with the usb 3.0 host controller. If I look at the usb analyzer, I see that the timing of the isochronous transfers using the usb 2.0 port is perfect?all the microframes are within 1uSec of being 125uSec apart.

Regarding the isochronous transfers, we are sending either 1 or 2 1024 byte packets of data every microframe. We transfer 150 packets this way, then there is a brief period of empty packets (15 or so microframes), before the next block of 150 packets is sent.

I?ve update the usb 3.0 host controllers to use the latest version of drivers (Renesas version 2.0.34.0). This happens to be the same version that is running on the Sony Vaio, which works fine.

Has anybody else experienced problems with isochronous transfers from a usb 2.0 device using a usb 3.0 host controller?

Thanks,
Jeff

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

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

5

I’m currently working with Renesas on the problem. It looks like the SOF is being sent every 125us with perfect timing, but the IN tokens for the isochronous data are not being sent with that same timing…the IN tokens are occasionally delayed, which end up causing data to be dropped. Renesas hasn’t yet taken ownership of the issue…their latest response was:

“Varied starting time jitter of IN transfer may have been due to some unrelated traffic on PCIe where the host controller resided. This is system/chipset dependent. And host controller has no control over that.”

I’ll update again once I hear more from them, and I’ll also pass along that we aren’t the only company seeing problems with isochronous transfers.

Jeff

6

Nope

d

debt from my phone

-----Original Message-----
From: Franz Detro
Sent: Tuesday, April 19, 2011 1:12 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] usb 2.0 isochronous transfers not working on a usb 3.0 host controller

Hi Doron,

Have you asked renesas? It is their stack’s issue.

my tries to find someone responsible at Renesas failed so far.

Do you have any contacts there?

d

Thanks,
Franz

debt from my phone

-----Original Message-----
From: xxxxx@gnotometrics.com
Sent: Tuesday, April 12, 2011 7:19 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] usb 2.0 isochronous transfers not working on a usb 3.0 host controller

Has anybody experienced any problems with usb 2.0 isochronous transfers using a laptop with usb 3.0?

We have a usb 2.0 device with a kernel mode device driver that uses isochronous transfers. The isochronous transfers have been working fine on a variety of laptops for the last 7 years. We?ve recently updated the driver to support Windows 7 (32 and 64 bit), and it?s running with the latest version of the WDK (7600). It?s working fine on a variety of XP, Vista, and Windows 7 systems that have usb 2.0 ports.

We have two test laptops that have usb 3.0 host controllers. Both are running 64 bit Windows 7. One is a Sony Viao, which works perfectly. The other is a Lenovo, and on this machine, in my kernel mode driver, I find that I?m ?losing? isochronous data. I?m examining the urbs that contain the isochronous data?they are not showing any errors, but some of the packets I?m expecting are missing.

If I look at the data on a usb analyzer, I see that all the data is in fact being sent across the usb bus. However, the timing of the packets is a little bit off. I should be seeing packets every 125uSec, but around 10% of the time, the interval between microframes is larger than this?falling between 126uSec and around 180uSec. I suspect that this is causing the usb 3.0 host controller to drop some of the data, due to it being an isochronous pipe.

I should also mention that this same laptop also has usb 2.0 ports. If I run our device on those ports, it works perfectly, so the problem seems to be with the usb 3.0 host controller. If I look at the usb analyzer, I see that the timing of the isochronous transfers using the usb 2.0 port is perfect?all the microframes are within 1uSec of being 125uSec apart.

Regarding the isochronous transfers, we are sending either 1 or 2 1024 byte packets of data every microframe. We transfer 150 packets this way, then there is a brief period of empty packets (15 or so microframes), before the next block of 150 packets is sent.

I?ve update the usb 3.0 host controllers to use the latest version of drivers (Renesas version 2.0.34.0). This happens to be the same version that is running on the Sony Vaio, which works fine.

Has anybody else experienced problems with isochronous transfers from a usb 2.0 device using a usb 3.0 host controller?

Thanks,
Jeff

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

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

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@gnotometrics.com wrote:

I’m currently working with Renesas on the problem. It looks like the SOF is being sent every 125us with perfect timing, but the IN tokens for the isochronous data are not being sent with that same timing…the IN tokens are occasionally delayed, which end up causing data to be dropped.

There is nothing in the USB specification that requires that an
isochronous pipe get its slot at the exact same point in every
microframe. Many people have created devices that assume that will be
the case, but that was just dangerously wishful thinking. Even though
most EHCI controllers do so, but that’s just an accident. As long as
you are getting an IN token in every microframe, Renesas is satisfying
the contract.

Renesas hasn’t yet taken ownership of the issue…their latest response was:

“Varied starting time jitter of IN transfer may have been due to some unrelated traffic on PCIe where the host controller resided. This is system/chipset dependent. And host controller has no control over that.”

Well, that’s a ridiculous excuse. Even though this is not, strictly
speaking, their problem. I would certainly want to understand what’s
causing it, but this excuse is nonsense. A PCIExpress connection is
point-to-point. There ISN’T any other traffic, and it’s impossible for
me to believe that the root complex is saturated.

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

8

> There is nothing in the USB specification that requires that an isochronous pipe get its slot at the > exact same point in every microframe. Many people have created devices that assume that will be > the case, but that was just dangerously wishful thinking. Even though most EHCI controllers do so, > but that’s just an accident. As long as you are getting an IN token in every microframe, Renesas is > satisfying the contract.

So if Renesas is sending an IN token with every microframe (which they are), and our device is responding with a data packet every microframe (which it is), then what determines when an isochronous packet is dropped? If I look at a USB analyzer trace, our device is responding to the IN token within 1 microsecond. If those packets aren?t all making it into the urb that is passed up to my driver, would that still point to a problem in the host controller, or is there another possibility?

9

(jumping-in mid thread)

The checksums might not match. That’s one reason data is dropped on ISO transfers.

Rare, in my experience, but possible.

Peter
OSR

10

Let me get that straight. You expect that IN tokens will be sent with perfect timing. That’s not going to happen. Your device should tolerate packets anywhere in the microframe window.

What if there is another ISO device on the host, and its driver is sending data of variable size, or receiving data of variable size, and their requests happen to be inserted before yours in the list? You’ll get the same jitter you see now.

11

xxxxx@gnotometrics.com wrote:

> There is nothing in the USB specification that requires that an isochronous pipe get its slot at the exact same point in every microframe. Many people have created devices that assume that will be the case, but that was just dangerously wishful thinking. Even though most EHCI controllers do so, but that’s just an accident. As long as you are getting an IN token in every microframe, Renesas is satisfying the contract.
So if Renesas is sending an IN token with every microframe (which they are), and our device is responding with a data packet every microframe (which it is), then what determines when an isochronous packet is dropped? If I look at a USB analyzer trace, our device is responding to the IN token within 1 microsecond. If those packets aren?t all making it into the urb that is passed up to my driver, would that still point to a problem in the host controller, or is there another possibility?

That’s a different case. If you are responding correctly and the
packets are being dropped, that sounds like a host controller issue, or
maybe even a cable or connector issue. That’s very different from the
host controller not issuing IN tokens.

This is a tricky issue. Isochronous pipes do not have guaranteed
delivery, but in actual practice I don’t think I’ve ever seen an
isochronous packet get dropped without some external influence.

It would be interesting to change your isochronous endpoints to
interrupt endpoints, and see if you get retries in the USB trace.
Unfortunately, that requires a driver change, because the URB format is
a little different.

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

12

xxxxx@broadcom.com wrote:

Let me get that straight. You expect that IN tokens will be sent with perfect timing. That’s not going to happen. Your device should tolerate packets anywhere in the microframe window.

Actually, based on his response, I don’t think that’s the issue he’s
seeing. He’s getting IN tokens and is responding, but the packets
aren’t getting back to his URB.

On the other hand, there are a lot of devices that do make exactly the
assumption you describe above.

What if there is another ISO device on the host, and its driver is sending data of variable size, or receiving data of variable size, and their requests happen to be inserted before yours in the list? You’ll get the same jitter you see now.

Well, that’s an implementation detail. That first device is entitled to
a fixed-size chunk of the frame. Whether or not it uses all of it
should be irrelevant. The host controller might issue the IN token for
the second device immediately after the first transfer completes, but it
also might wait until the scheduled time for the second device.

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

13

“Well, that’s an implementation detail. That first device is entitled to
a fixed-size chunk of the frame. Whether or not it uses all of it
should be irrelevant.”

Well, as far as I know, there’s only been bandwidth guarantee for ISO transfers. It’s never been a timing guarantee or any ordering with unrelated devices on the same host. Even if they’re always sending data of unchanged size, they may get reordered against each other, as they submit new URBs.

“but it also might wait until the scheduled time for the second device.”

OHCI/UHCI didn’t do that.

14

xxxxx@broadcom.com wrote:

Well, as far as I know, there’s only been bandwidth guarantee for ISO transfers. It’s never been a timing guarantee or any ordering with unrelated devices on the same host. Even if they’re always sending data of unchanged size, they may get reordered against each other, as they submit new URBs.

You are entirely correct. There is no guarantee. The EHCI behavior has
been very consistent, however, and I think that has led people to assume
things that are not part of the contract.

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

15

I suspect it’s physical layer issues. I’m not sure if for iso transfers there is any error reporting in case of CRC mismatch.

16

xxxxx@broadcom.com wrote:

I suspect it’s physical layer issues. I’m not sure if for iso transfers there is any error reporting in case of CRC mismatch.

Again, what you say is correct, and I don’t want you to think I’m
contradicting you. If there are physical layer issues causing packet
damage, those packets will disappear silently

The point I’m trying to make is that, to 6 decimal places, such errors
simply do not happen in real life. Unless there is a faulty cable or a
bad connector, you can run quite literally billions of isochronous
packets and never have one get dropped.

Are there are issues running USB 2 cables into USB 3 connectors? Maybe,
but that’s a test that easy to do.

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

17

“The point I’m trying to make is that, to 6 decimal places, such errors
simply do not happen in real life.”

In real life, not every OEM can even get good physical layer for 480 Mbps. A few years ago, I’ve had a mainboard of tier 2 brand (A**S). On that mainboard, 480 Mbps never worked even without a cable - flash sticks only worked somehow in certain USB sockets. Even though it was Intel chipset. Solution was: disable EHCI. (Im)proper PCB design makes a lot of difference.

In old days, even USB 1.1 hosts of some vendors were flakey.