USB 1.1 device at USB 2.0 Hub shows unexpected behavior

NTDEV
1

Hello there,

I have a USB 1.1 (2.0 “compliant”) Full Speed device for which I
maintain the firmware and the Windows driver.
The USB controller is an Atmel AT895131.

Connected to a Windows XP PC directly at the PCs USB port shows a
millisecond timing of the round trip messages.
I can see in the driver that every message is transmitted within one
frame, so one roundtrip message lasts 3-4 milliseconds:

  1. Request message from the host.
  2. Ack from device
  3. Response from device

But if I use an external USB 2.0 Hub between the device and the Host PC,
the roundtrip time decreases dramatically to 250 - 500 microseconds
which seems to be the microframe timing of USB 2.0.

How can that work with my USB 1.1 device? Why is the behavior different
if I connect the device directly to my PCs USB 2.0 port?
In fact, the performance of my device is even better with the Hub
because I need low latency values, but what is the reason for this?

Kind regards,
Daniel Boldt

2

Daniel Boldt wrote:

But if I use an external USB 2.0 Hub between the device and the
Host PC, the roundtrip time decreases dramatically to 250 - 500
microseconds which seems to be the microframe timing of USB
2.0. How can that work with my USB 1.1 device? Why is the
behavior different if I connect the device directly to my PCs
USB 2.0 port?

First, let me say I’ve definitely witnessed this behavior also, so you’re not alone. Now, second, consider that when using a 2.0 hub, your device is now routed through the EHCI USB stack on the host side (as opposed to UHCI or what not). My conclusion is that this stack (usbehci.sys and so on) simply has a higher level of performance (/ lower latency) than the 1.1 ones. I could be wrong, though.

3

There’s a WHOLE lot about USB that – despite having (at least attempted) to read the (lengthy, confusing, and enormous) spec several times, I don’t understand.

Have either of you put a bus analyzer on this to actually be able to characterize/describe the actual behavior??

Peter
OSR

4

You wrote:

There’s a WHOLE lot about USB that – despite having (at least
attempted) to read the (lengthy, confusing, and enormous) spec
several times, I don’t understand.

My experience is that, as specs go, the USB spec is quite readable. Have you ever tried to wade through the PCI or PCIExpress specs?

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

5

xxxxx@osr.com wrote:

There’s a WHOLE lot about USB that – despite having (at least
attempted) to read the (lengthy, confusing, and enormous) spec
several times, I don’t understand.

IMO, the USB 2.0 spec is quite short and well written (as specs go), and
usually I only have to refer to Chapters 9 (34p) and 8 (43p). Only if
you have to delve into the device classes, it may become lengthy.

Oh… possibly you refer to the Microsoft USB documentation…
*That* one is of course a completely different thing… :wink:

6

I think this issue has to do with EHCI/OHCI/UHCI specs more than with the core USB spec.

The OP doesn’t say what kind of transfer this happens on, but I guess it is on a Control pipe, right?

When a 1.1 device is connected to an EHCI controller’s root port, it connects to the companion HC (either a OHCI or UHCI controller). When a 1.1 device connects to a EHCI controller through an external 2.0 hub, it connects to the EHCI controller instead.

Per the UHCI spec (don’t have a reference for this now, sorry), a UHCI controller will perform only one Control transaction per frame (1ms). So when you have a standard control request sequence, say:

SETUP
DATA0
ACK

IN
DATA1
ACK
(Mutiple IN transactions may happen to complete the overall request, if transfer size is greater than endpoint size.)

OUT
DATA1
ACK

each transaction will be in its own frame (the last OUT ending the transfer might be immediately after the final IN - i have forgotten).

However, with EHCI and OHCI controllers, multiple control transactions can happen within the same frame. Therefore, if the HW is fast enough, it can process the SETUP, IN (x N) and OUT transactions within one frame (1ms).

I am guessing that this might explain the behavior you are seeing. (If you have an OHCI controller laying around, you might be able to see the same phenomenon using it too.)

Hope this helps,
Srdjan

7

I’d agree with below explanation and suggest following experiment. Put
USB analyser between hub and device and then between hub and HC and
compare results. Ideally, use two analysers at once. Between hub and HC
it has to be 2.0 analyser.

The OHCI part is also right. With OHCI you can achieve much better
performance on control channel. In the driver it can be worthwhile to
queue several control transfers at once at OHCI. At UHCI it doesn’t
matter; it is so slow that performance is the same if you wait until
every transfer completion and then send the next one.

(Personally, I’d outlaw UHCI :slight_smile:

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@digitalpersona.com
Sent: Friday, October 03, 2008 8:39 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] USB 1.1 device at USB 2.0 Hub shows
unexpected behavior

I think this issue has to do with EHCI/OHCI/UHCI specs more
than with the core USB spec.

The OP doesn’t say what kind of transfer this happens on, but
I guess it is on a Control pipe, right?

When a 1.1 device is connected to an EHCI controller’s root
port, it connects to the companion HC (either a OHCI or UHCI
controller). When a 1.1 device connects to a EHCI controller
through an external 2.0 hub, it connects to the EHCI
controller instead.

Per the UHCI spec (don’t have a reference for this now,
sorry), a UHCI controller will perform only one Control
transaction per frame (1ms). So when you have a standard
control request sequence, say:

SETUP
DATA0
ACK

IN
DATA1
ACK
(Mutiple IN transactions may happen to complete the overall
request, if transfer size is greater than endpoint size.)

OUT
DATA1
ACK

each transaction will be in its own frame (the last OUT
ending the transfer might be immediately after the final IN -
i have forgotten).

However, with EHCI and OHCI controllers, multiple control
transactions can happen within the same frame. Therefore,
if the HW is fast enough, it can process the SETUP, IN (x N)
and OUT transactions within one frame (1ms).

I am guessing that this might explain the behavior you are
seeing. (If you have an OHCI controller laying around, you
might be able to see the same phenomenon using it too.)

Hope this helps,
Srdjan

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

8

Thanks for the hints.

I could confirm that different host controller drivers are used when
either using or not using the USB 2.0 hub between device and HOST
(usbuhci.sys or usbehci.sys).
I will investigate on this with a USB analyser.

Thanks!

Regards,
Daniel Boldt

Michal Vodicka wrote:

I’d agree with below explanation and suggest following experiment. Put
USB analyser between hub and device and then between hub and HC and
compare results. Ideally, use two analysers at once. Between hub and HC
it has to be 2.0 analyser.

The OHCI part is also right. With OHCI you can achieve much better
performance on control channel. In the driver it can be worthwhile to
queue several control transfers at once at OHCI. At UHCI it doesn’t
matter; it is so slow that performance is the same if you wait until
every transfer completion and then send the next one.

(Personally, I’d outlaw UHCI :slight_smile:

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> xxxxx@digitalpersona.com
> Sent: Friday, October 03, 2008 8:39 AM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] USB 1.1 device at USB 2.0 Hub shows
> unexpected behavior
>
> I think this issue has to do with EHCI/OHCI/UHCI specs more
> than with the core USB spec.
>
> The OP doesn’t say what kind of transfer this happens on, but
> I guess it is on a Control pipe, right?
>
> When a 1.1 device is connected to an EHCI controller’s root
> port, it connects to the companion HC (either a OHCI or UHCI
> controller). When a 1.1 device connects to a EHCI controller
> through an external 2.0 hub, it connects to the EHCI
> controller instead.
>
> Per the UHCI spec (don’t have a reference for this now,
> sorry), a UHCI controller will perform only one Control
> transaction per frame (1ms). So when you have a standard
> control request sequence, say:
>
> SETUP
> DATA0
> ACK
>
> IN
> DATA1
> ACK
> (Mutiple IN transactions may happen to complete the overall
> request, if transfer size is greater than endpoint size.)
>
> OUT
> DATA1
> ACK
>
> each transaction will be in its own frame (the last OUT
> ending the transfer might be immediately after the final IN -
> i have forgotten).
>
> However, with EHCI and OHCI controllers, multiple control
> transactions can happen within the same frame. Therefore,
> if the HW is fast enough, it can process the SETUP, IN (x N)
> and OUT transactions within one frame (1ms).
>
> I am guessing that this might explain the behavior you are
> seeing. (If you have an OHCI controller laying around, you
> might be able to see the same phenomenon using it too.)
>
> Hope this helps,
> Srdjan
>
>
>
>
>
>
> —
> 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

9

By the way, which USB analyzer are you using guys ?
I used in the past some CATC devices but find them pretty basic.

Inaki.

-----Mensaje original-----
De: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] En nombre de Daniel Boldt
Enviado el: lunes, 06 de octubre de 2008 11:50
Para: Windows System Software Devs Interest List
Asunto: Re: [ntdev] USB 1.1 device at USB 2.0 Hub shows unexpected behavior

Thanks for the hints.

I could confirm that different host controller drivers are used when either using or not using the USB 2.0 hub between device and HOST (usbuhci.sys or usbehci.sys).
I will investigate on this with a USB analyser.

Thanks!

Regards,
Daniel Boldt

Michal Vodicka wrote:

I’d agree with below explanation and suggest following experiment. Put
USB analyser between hub and device and then between hub and HC and
compare results. Ideally, use two analysers at once. Between hub and
HC it has to be 2.0 analyser.

The OHCI part is also right. With OHCI you can achieve much better
performance on control channel. In the driver it can be worthwhile to
queue several control transfers at once at OHCI. At UHCI it doesn’t
matter; it is so slow that performance is the same if you wait until
every transfer completion and then send the next one.

(Personally, I’d outlaw UHCI :slight_smile:

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> xxxxx@digitalpersona.com
> Sent: Friday, October 03, 2008 8:39 AM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] USB 1.1 device at USB 2.0 Hub shows unexpected
> behavior
>
> I think this issue has to do with EHCI/OHCI/UHCI specs more than with
> the core USB spec.
>
> The OP doesn’t say what kind of transfer this happens on, but I guess
> it is on a Control pipe, right?
>
> When a 1.1 device is connected to an EHCI controller’s root port, it
> connects to the companion HC (either a OHCI or UHCI controller). When
> a 1.1 device connects to a EHCI controller through an external 2.0
> hub, it connects to the EHCI controller instead.
>
> Per the UHCI spec (don’t have a reference for this now, sorry), a
> UHCI controller will perform only one Control transaction per frame
> (1ms). So when you have a standard control request sequence, say:
>
> SETUP
> DATA0
> ACK
>
> IN
> DATA1
> ACK
> (Mutiple IN transactions may happen to complete the overall request,
> if transfer size is greater than endpoint size.)
>
> OUT
> DATA1
> ACK
>
> each transaction will be in its own frame (the last OUT ending the
> transfer might be immediately after the final IN - i have forgotten).
>
> However, with EHCI and OHCI controllers, multiple control
> transactions can happen within the same frame. Therefore, if the HW
> is fast enough, it can process the SETUP, IN (x N) and OUT
> transactions within one frame (1ms).
>
> I am guessing that this might explain the behavior you are seeing.
> (If you have an OHCI controller laying around, you might be able to
> see the same phenomenon using it too.)
>
> Hope this helps,
> Srdjan
>
>
>
>
>
>
> —
> 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