about Usb Token

NTDEV
1

Hi Usb experts
as my understand usb spec, all kinds of the token are send by host controller (root hub). My question is how the host to know the condition the endpoin has data to be sent to host,espeically for interrutpt in token . it looks like host controller pooling the endpoint indicated by spec. it is so inefficient if it is true.
And I also analyze the sniffer log, My confuse is that the is no pooling “in token” from host when no data in the endpoint.It look the host controller is so smart.

thanks
donglw

2

“rech dong” wrote in message news:xxxxx@ntdev…
>
> Hi Usb experts
> as my understand usb spec, all kinds of the token are send by host
> controller (root hub). My question is how the host to know the condition
> the endpoin has data to be sent to host,espeically for interrutpt in token
> . it looks like host controller pooling the endpoint indicated by spec.
> it is so inefficient if it is true.

Yes, it works by polling, and this is indeed inefficient.

> My confuse is that the is no pooling “in token” from host when no data in
> the endpoint.It look the host controller is so smart.

The host controller is smart, but not psychic.It must poll all the time -
except when the device is in suspend state. Is it?

–pa

3

>it is so inefficient if it is true.

Yes, it is true, and yes, life is inefficient :slight_smile:

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

4

I have two concerns:

  1. the pooling method will become more bad as devices(or endpoint) number increasing in a single controller bus. the max number of device is 128. and the normal a single device may have more than one endpoint. that will affect the througput of total system. I saw most of pc have only 3-4 usb ports but there are as many as 8 controllers in system.
    Is manboard vendor in tend to decrease the effact by increasing the controllers?
  2. for host client driver and controller driver. for “in endpoint” , the host client driver has no other choice except using pingpong irp method to read data from endpoint.
    I am thinking: if client driver has “in irp” pending in controller driver, does the controller driver still need controller hw sending “in token” repedetly?

thanks
donglw

From: xxxxx@storagecraft.com
Subject: Re:[ntdev] about Usb Token
Date: Fri, 26 Nov 2010 01:44:39 +0300
To: xxxxx@lists.osr.com

>it is so inefficient if it is true.

Yes, it is true, and yes, life is inefficient :slight_smile:

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

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

fix a typo .

From: xxxxx@hotmail.com
To: xxxxx@lists.osr.com
Subject: RE: [ntdev] about Usb Token
Date: Fri, 26 Nov 2010 02:53:42 +0000

I have two concerns:

  1. the pooling method will become more bad as devices(or endpoint) number increasing in a single controller bus. the max number of device is 128. and the normal a single device may have more than one endpoint. that will affect the througput of total system. I saw most of pc have only 3-4 usb ports but there are as many as 8 controllers in system.
    Is manboard vendor in tend to decrease the effact by increasing the controllers?
  2. for host client driver and controller driver. for “in endpoint” , the host client driver has no other choice except using pingpong irp method to read data from endpoint.
    I am thinking: if client driver has no “in irp” pending in controller driver, does the controller driver still need controller hw sending “in token” repedetly?

thanks
donglw

From: xxxxx@storagecraft.com
Subject: Re:[ntdev] about Usb Token
Date: Fri, 26 Nov 2010 01:44:39 +0300
To: xxxxx@lists.osr.com

>it is so inefficient if it is true.

Yes, it is true, and yes, life is inefficient :slight_smile:

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

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

6

  1. Only the endpoints with pending URBs will be polled. While many devices may have several endpoints, many of those endpoints are idle (no IO pending). With interrupt endpoints, the polling rate is moderated by the bInterval value in the endpoint descriptor. This helps to mitigate the inefficiency of leaving an IN transfer pending on that endpoint. Increasing the number of controllers will help reduce the number of devices attached to a single controller, which will increase the efficiency of each controller.

  2. The host controller will ONLY poll an endpoint if there is an irp pending for that endpoint.

Note that USB 3.0 addresses this efficiency issue by providing an asynchronous notification from the device to the host indicating that an endpoint is ready. In this case, the controller would poll then endpoint once, if the endpoint NAKs (NRDY), the controller will no longer poll it. Later the device sends an ERDY token to the host, at which point the controller will poll the endpoint again. This way, idle endpoints (even ones with transfers pending) will not consume bus bandwidth.

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of rech dong
Sent: Thursday, November 25, 2010 6:57 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] about Usb Token

fix a typo .

From: xxxxx@hotmail.com
To: xxxxx@lists.osr.com
Subject: RE: [ntdev] about Usb Token
Date: Fri, 26 Nov 2010 02:53:42 +0000

I have two concerns:

  1. the pooling method will become more bad as devices(or endpoint) number increasing in a single controller bus. the max number of device is 128. and the normal a single device may have more than one endpoint. that will affect the througput of total system. I saw most of pc have only 3-4 usb ports but there are as many as 8 controllers in system.
    Is manboard vendor in tend to decrease the effact by increasing the controllers?
  2. for host client driver and controller driver. for “in endpoint” , the host client driver has no other choice except using pingpong irp method to read data from endpoint.
    I am thinking: if client driver has no “in irp” pending in controller driver, does the controller driver still need controller hw sending “in token” repedetly?

thanks
donglw

From: xxxxx@storagecraft.commailto:xxxxx
> Subject: Re:[ntdev] about Usb Token
> Date: Fri, 26 Nov 2010 01:44:39 +0300
> To: xxxxx@lists.osr.commailto:xxxxx
>
> >it is so inefficient if it is true.
>
> Yes, it is true, and yes, life is inefficient :slight_smile:
>
> –
> Maxim S. Shatskih
> Windows DDK MVP
> xxxxx@storagecraft.commailto:xxxxx
> http://www.storagecraft.com
>
>
> —
> 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</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

7

It’s very helpful .thank you very much.

thanks
donglw

From: xxxxx@microsoft.com
To: xxxxx@lists.osr.com
Subject: RE: [ntdev] about Usb Token
Date: Fri, 26 Nov 2010 21:25:46 +0000

  1. Only the endpoints with pending URBs will be polled. While many devices may have several endpoints, many of those endpoints are idle (no IO pending). With interrupt endpoints, the polling rate is moderated by the bInterval value in the endpoint descriptor. This helps to mitigate the inefficiency of leaving an IN transfer pending on that endpoint. Increasing the number of controllers will help reduce the number of devices attached to a single controller, which will increase the efficiency of each controller.2. The host controller will ONLY poll an endpoint if there is an irp pending for that endpoint. Note that USB 3.0 addresses this efficiency issue by providing an asynchronous notification from the device to the host indicating that an endpoint is ready. In this case, the controller would poll then endpoint once, if the endpoint NAKs (NRDY), the controller will no longer poll it. Later the device sends an ERDY token to the host, at which point the controller will poll the endpoint again. This way, idle endpoints (even ones with transfers pending) will not consume bus bandwidth. From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of rech dong
    Sent: Thursday, November 25, 2010 6:57 PM
    To: Windows System Software Devs Interest List
    Subject: RE: [ntdev] about Usb Token fix a typo .
    From: xxxxx@hotmail.com
    To: xxxxx@lists.osr.com
    Subject: RE: [ntdev] about Usb Token
    Date: Fri, 26 Nov 2010 02:53:42 +0000

I have two concerns:

  1. the pooling method will become more bad as devices(or endpoint) number increasing in a single controller bus. the max number of device is 128. and the normal a single device may have more than one endpoint. that will affect the througput of total system. I saw most of pc have only 3-4 usb ports but there are as many as 8 controllers in system.
    Is manboard vendor in tend to decrease the effact by increasing the controllers?
  2. for host client driver and controller driver. for “in endpoint” , the host client driver has no other choice except using pingpong irp method to read data from endpoint.
    I am thinking: if client driver has no “in irp” pending in controller driver, does the controller driver still need controller hw sending “in token” repedetly?

thanks
donglw

From: xxxxx@storagecraft.com
Subject: Re:[ntdev] about Usb Token
Date: Fri, 26 Nov 2010 01:44:39 +0300
To: xxxxx@lists.osr.com

>it is so inefficient if it is true.

Yes, it is true, and yes, life is inefficient :slight_smile:

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

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

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

> 1. the pooling method will become more bad as devices(or endpoint) number increasing in a single

controller bus.

Yes.

the max number of device is 128. and the normal a single device may have more than one endpoint.
that will affect the througput of total system.

Yes it will. And yes, USB is such.

Is manboard vendor in tend to decrease the effact by increasing the controllers?

Probably.

I am thinking: if client driver has “in irp” pending in controller driver, does the controller driver still
need controller hw sending “in token” repedetly?

Surely yes. How the target hardware will know that there is an IRP?

More so: pinging occurs only if there is a pending IRP.

USB is simple and surely not so sophisticated. Yes, in USB, the host drives everything, and the targets are extremely dumb and simple, thus being cheap.

If you want more sophisticated bus - use 1394. Note that it is losing market to USB, especially when miniDV camcorders are obsolete and eSATA is widespread (the 2 primary uses for 1394).

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

9

Yes, USB is a terrible bus, but it may be a little better with USB 3.0.
There is a new bus Apple is adding that runs at 10Gbps. I saw a report on
it this week. I think Intel or another vendor participated in its
invention/implementation but Apple gets it exclusive for some period of
time. 1394a/b seems to be falling with even Apple not supporting it on
several/many of their new platforms.

“Maxim S. Shatskih” wrote in message news:xxxxx@ntdev…

  1. the pooling method will become more bad as devices(or endpoint)
    number increasing in a single
    controller bus.

Yes.

the max number of device is 128. and the normal a single device may have
more than one endpoint.
that will affect the througput of total system.

Yes it will. And yes, USB is such.

Is manboard vendor in tend to decrease the effact by increasing the
controllers?

Probably.

I am thinking: if client driver has “in irp” pending in controller
driver, does the controller driver still
need controller hw sending “in token” repedetly?

Surely yes. How the target hardware will know that there is an IRP?

More so: pinging occurs only if there is a pending IRP.

USB is simple and surely not so sophisticated. Yes, in USB, the host drives
everything, and the targets are extremely dumb and simple, thus being cheap.

If you want more sophisticated bus - use 1394. Note that it is losing market
to USB, especially when miniDV camcorders are obsolete and eSATA is
widespread (the 2 primary uses for 1394).

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

10

> Yes, USB is a terrible bus

…and surely the designers were not stupid, and these drawbacks (to which I can add the software complexity on the host side) are the tradeoffs.

Tradeoffs for what? target simplicity seems to be #1, HC hardware simplicity is maybe #2.

Just compare USB with 1394 and its SelfID phases, which probably require as many gates in the PHY larger as the whole USB HC (and targets are must simpler).

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

11

Consider when it was designed and the goals of the designers… It’s really not so bad. In terms of whether polling is efficient or not… Consider that devices can reserve bandwidth for specific endpoints.

As Max said the design results in a bus in which devices can be produced at very low cost (have you seen the USB sound cards available on ebay for less than US$1??), fully supports plug and play, and isn’t obsolete even this long after it’s design.

Not bad if you ask me,

Peter
OSR

12

Peter Viscarola wrote:

As Max said the design results in a bus in which devices
can be produced at very low cost (have you seen the USB
sound cards available on ebay for less than US$1??), fully
supports plug and play, and isn’t obsolete even this long
after it’s design.

Not bad if you ask me,

Indeed:

http://www.youtube.com/watch?v=fFKwnHJQXsY

('cept, that isn’t really Ajay Bhatt, apparently…)

13

On 11/28/2010 5:01 PM, xxxxx@osr.com wrote:

[…] and isn’t obsolete even this long after it’s design.

Well, last week someone asked if they could use an old parallel port
device variant of our product. With Win7/64bit. Via USB converter(!).

Compared to the COM/LPT port woes I remember (including a wrecked I/F
card when someone hot-plugged a printer), USB is a big step forward.

For the end user. Unfortunately -at least initially- not for developers.

'Legacy I/F’s were removed, but no simple way to send/receive a few
data bytes was included in Windows. Hence the abundance of BulkUSB-
derived drivers – which are still necessary for any HW that has to run
with any pre-XP box (think embedded devices with a really small memory
footprint). Anything else can use WinUSB and UMDF.

But I really wonder how things will go for USB3.?

14

Excellent observation, and somewhat embarrassingly one that never occurred to me.

It’s too bad there wasn’t a standard developed early-on that would replace the ubiquitous serial and parallel interfaces. Something like a “USB Byte Data Service” – a service that just provided raw byte input and output, and did bulk IN and OUT service under the covers.

That would have eliminated the need for vendors to develop their own (mostly silly) bulk drivers.

Peter
OSR

15

Peter Viscarola (OSR) wrote:

Something like a “USB Byte Data Service” – a service that
just provided raw byte input and output, and did bulk IN and
OUT service under the covers.

That would have eliminated the need for vendors to develop
their own (mostly silly) bulk drivers.

I’ve observed many vendors implementing a generic HID device to accomplish this.

16

>parallel interfaces. Something like a “USB Byte Data Service”

I just plain cannot understand why MS have not provided the ability for the user-mode code to open the USB pipe (say bulk one) using the reference string like “\pipe0” or such, with several IOCTLs to get the config descriptors.

I think this would be much simpler and more flexible then WinUSB, and many USB drivers (like printing) will be gone in favour of user-mode DLLs.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

17

> I’ve observed many vendors implementing a generic HID device to accomplish this.

Most UPSes, for instance.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

18

We first did that HID trick 10 years ago with the aid of John Hyde’s starter
book “USB Design by Example” for our hardware box. It was very slow though
for anything more than a handful of bytes so we had to do the (painful at
the time) trivial bulk driver.

I assume these days anyone needing a simple byte exchange at RS232 type
speeds can do a UMDF bulk i/o driver. Would that be the way for a small
developer these days? Does it bypass the requirement to sign for 64-bit? I
was not clear on that from reading so far.

Another way is to embed a standard USB/RS232 adaptor in the hardware and
pretend it’s a comm port.

Mike

>>>>>>>>>>>>>>>From: xxxxx@gmail.com
To: Windows System Software Devs Interest List
Sent: Monday, November 29, 2010 4:06 PM
Subject: RE:[ntdev] about Usb Token

Peter Viscarola (OSR) wrote:

Something like a “USB Byte Data Service” – a service that
just provided raw byte input and output, and did bulk IN and
OUT service under the covers.

That would have eliminated the need for vendors to develop
their own (mostly silly) bulk drivers.

I’ve observed many vendors implementing a generic HID device to accomplish
this.

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

19

On 11/29/2010 5:22 PM, Mike Kemp wrote:

I assume these days anyone needing a simple byte exchange at RS232 type
speeds can do a UMDF bulk i/o driver. Would that be the way for a small
developer these days? Does it bypass the requirement to sign for 64-bit?
I was not clear on that from reading so far.

No, you could use the MS-provided WinUSB driver directly from the
application. (If I understood correctly, there is no need for UMDF or
KMDF, you need only an INF file to register your VID/PID with WinUSB.)

My fear for USB3 is that MS will wait too long until they fully and
transparently integrate it into the USB stack. Meanwhile ISVs will have
to provide lots of different drivers. Then - once this is “settled” - we
can’t clean up b/c of the need for legacy support. Let’s see…

20

Depends on what you mean by “too long” :wink:

Welcome to the world of “we won’t tell you anything until it’s cooked.”

I’ll tell you ONE thing: The reason we don’t have this information IS NOT because the devs don’t realize it could be helpful. It’s because of the SteveSi rules mentioned many times on this list.

Peter
OSR