Bulkusb.sys performance

hi,
I have adapted bulkusb.sys (WDK 6000) for my usb device driver. With
the driver communicating on interrupt endpoint i am not able to get
performance more than 15Mbits/sec. However with the same device and
application but driver from "thesycon" i.e. USBIO, performance is
about 80Mbits/sec.

Can some one tell why ? or if someone has the performance figures of
bulkusb.sys or if some can guide how to improve the performance.

Regards,

Doron
Wed Jan 30 12:00:24 CST 2008

do you have more than one pending transfer on the interrupt at one time?
e.g. send 5 transfers at once on the interrupt endpoint to make sure that
there is always a transfer pending on the schedule.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"xxx" <anshul.solanki@gmail.com> wrote in message
news:9f314e43-ee4b-4447-a9b1-7c55d1a815ed@b2g2000hsg.googlegroups.com...
> hi,
> I have adapted bulkusb.sys (WDK 6000) for my usb device driver. With
> the driver communicating on interrupt endpoint i am not able to get
> performance more than 15Mbits/sec. However with the same device and
> application but driver from "thesycon" i.e. USBIO, performance is
> about 80Mbits/sec.
>
> Can some one tell why ? or if someone has the performance figures of
> bulkusb.sys or if some can guide how to improve the performance.
>
> Regards,

xxx
Wed Jan 30 21:33:51 CST 2008

On Jan 30, 11:00=A0pm, "Doron Holan [MSFT]"
<dor...@online.microsoft.com> wrote:
> do you have more than one pending transfer on the interrupt at one time?
> e.g. send 5 transfers at once on the interrupt endpoint to make sure that
> there is always a transfer pending on the schedule.

My understanding is this
1) if i initiate large chunk from user side ...the kernel
driver(either bulkusb.sys or miniport driver) should break that in
smaller chunck and load data on bus. i.e

nbBytes =3D 50000;
if (!WriteFile(hWriteCom, (void *)(sBuff), nbBytes, &WrittenBytes,
&Event))
{
// Error in communications
if (GetLastError() !=3D ERROR_IO_PENDING)
{
Error =3D FALSE;
}
else // wait for writing to be completed
{
// Write event is pending.
dwRes =3D WaitForSingleObject(Event.hEvent, INFINITE);

switch(dwRes)
{
// waited event (write) is signaled
case WAIT_OBJECT_0:
// check event result (is writing OK?)
if (!GetOverlappedResult(hWriteCom, &Event, &WrittenBytes,
FALSE))
{
Error =3D FALSE;
}
break;

// Error in the WaitForSingleObject
default:
Error =3D FALSE;
break;
}
} // if (GetLastError()...
} //if (!WriteFile
}

2) so this WriteFile() i am requesting 50K bytes to be written, hence
there is always data to be sent. Hence driver should load bus, but i
see in CATC that between two SOF only single packet of 512 is sent.

Doron, is it not same or more efficient as making 5 transfers? Am i
missing something ?

Regards,
Anshul

Tim
Thu Jan 31 00:14:20 CST 2008

xxx <anshul.solanki@gmail.com> wrote:
>
>I have adapted bulkusb.sys (WDK 6000) for my usb device driver. With
>the driver communicating on interrupt endpoint i am not able to get
>performance more than 15Mbits/sec. However with the same device and
>application but driver from "thesycon" i.e. USBIO, performance is
>about 80Mbits/sec.

Even that is not much. We've sustained 360 Mbps on a USB bulk pipe, using
a driver derived from bulkusb.sys.

>Can some one tell why ? or if someone has the performance figures of
>bulkusb.sys or if some can guide how to improve the performance.

Doron has the key. You **MUST** make sure that the host controller driver
never runs out of IRPs from your driver. If it runs dry, it will stop
making requests, and you'll lose an entire microframe or more.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

xxx
Thu Jan 31 02:27:18 CST 2008

On Jan 31, 11:14=A0am, Tim Roberts <t...@probo.com> wrote:
> xxx <anshul.sola...@gmail.com> wrote:
>
> >I have adapted bulkusb.sys (WDK 6000) for my usb device driver. With
> >the driver communicating on interrupt endpoint i am not able to get
> >performance more than 15Mbits/sec. However with the same device and
> >application but driver from "thesycon" i.e. USBIO, performance is
> >about 80Mbits/sec.
>
> Even that is not much. =A0We've sustained 360 Mbps on a USB bulk pipe, usi=
ng
> a driver derived from bulkusb.sys.
>
> >Can some one tell why ? or if someone has the performance figures of
> >bulkusb.sys or if some can guide how to improve the performance.
>
> Doron has the key. =A0You **MUST** make sure that the host controller driv=
er
> never runs out of IRPs from your driver. =A0If it runs dry, it will stop
> making requests, and you'll lose an entire microframe or more.
> --
> Tim Roberts, t...@probo.com
> Providenza & Boekelheide, Inc.

Does it imply
1) change in user mode application to do asyncronous write / queuing
completion routine etc?
2) change in bulkusb driver ?

Regards,
Anshul

chris
Thu Jan 31 08:55:49 CST 2008

On Jan 31, 2:27 am, xxx <anshul.sola...@gmail.com> wrote:

> On Jan 31, 11:14 am, Tim Roberts <t...@probo.com> wrote:
>
> > Doron has the key. You **MUST** make sure that the host controller driver
> > never runs out of IRPs from your driver. If it runs dry, it will stop
> > making requests, and you'll lose an entire microframe or more.
>
> Does it imply
> 1) change in user mode application to do asyncronous write / queuing
> completion routine etc?
> 2) change in bulkusb driver ?

Either one, it depends on how you've set up your driver. You can
either establish a buffer in your driver and have it continuously read
from the device (via multiple submitted URBs), or have the driver just
pass through IOCTLs from userspace that it converts into URBs (and
your userspace app submits many IOCTLs overlapped).

I don't personally know the performance characteristics of each
approach, but my guess is that the former would be faster.

Alexander
Thu Jan 31 09:10:31 CST 2008

You problem is in using an interrupt endpoint, which limits its bandwidth.
Use bulk endpoint. You don't have to change any code to switch, only
endpoint descriptor.

"xxx" <anshul.solanki@gmail.com> wrote in message
news:9f314e43-ee4b-4447-a9b1-7c55d1a815ed@b2g2000hsg.googlegroups.com...
> hi,
> I have adapted bulkusb.sys (WDK 6000) for my usb device driver. With
> the driver communicating on interrupt endpoint i am not able to get
> performance more than 15Mbits/sec. However with the same device and
> application but driver from "thesycon" i.e. USBIO, performance is
> about 80Mbits/sec.
>
> Can some one tell why ? or if someone has the performance figures of
> bulkusb.sys or if some can guide how to improve the performance.
>
> Regards,

Doron
Thu Jan 31 13:29:13 CST 2008

note that bulk endpoints do not get guaranteed bandwidth, while an interrupt
endpoint does. so while you can shuttle more data over a bulk EP vs a int
EP on an idle usb bus, on a heavily loaded bus, the INT ep may win out

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Alexander Grigoriev" <alegr@earthlink.net> wrote in message
news:uR4DttBZIHA.4180@TK2MSFTNGP06.phx.gbl...
> You problem is in using an interrupt endpoint, which limits its bandwidth.
> Use bulk endpoint. You don't have to change any code to switch, only
> endpoint descriptor.
>
> "xxx" <anshul.solanki@gmail.com> wrote in message
> news:9f314e43-ee4b-4447-a9b1-7c55d1a815ed@b2g2000hsg.googlegroups.com...
>> hi,
>> I have adapted bulkusb.sys (WDK 6000) for my usb device driver. With
>> the driver communicating on interrupt endpoint i am not able to get
>> performance more than 15Mbits/sec. However with the same device and
>> application but driver from "thesycon" i.e. USBIO, performance is
>> about 80Mbits/sec.
>>
>> Can some one tell why ? or if someone has the performance figures of
>> bulkusb.sys or if some can guide how to improve the performance.
>>
>> Regards,
>
>

Alexander
Thu Jan 31 20:54:45 CST 2008

You can get the most of a bulk endpoint, over 40 MB/s. Interrupt endpoint
only guarantees quite little percentage of USB throughput and it won't give
more, whether it's currently used or not. Even iso endpoint will only go up
to 24 MB/s.

"Doron Holan [MSFT]" <doronh@online.microsoft.com> wrote in message
news:eXwnQ%23DZIHA.208@TK2MSFTNGP02.phx.gbl...
> note that bulk endpoints do not get guaranteed bandwidth, while an
> interrupt endpoint does. so while you can shuttle more data over a bulk
> EP vs a int EP on an idle usb bus, on a heavily loaded bus, the INT ep may
> win out
>
> d
>
> --
> Please do not send e-mail directly to this alias. this alias is for
> newsgroup purposes only.
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
>
> "Alexander Grigoriev" <alegr@earthlink.net> wrote in message
> news:uR4DttBZIHA.4180@TK2MSFTNGP06.phx.gbl...
>> You problem is in using an interrupt endpoint, which limits its
>> bandwidth.
>> Use bulk endpoint. You don't have to change any code to switch, only
>> endpoint descriptor.
>>
>> "xxx" <anshul.solanki@gmail.com> wrote in message
>> news:9f314e43-ee4b-4447-a9b1-7c55d1a815ed@b2g2000hsg.googlegroups.com...
>>> hi,
>>> I have adapted bulkusb.sys (WDK 6000) for my usb device driver. With
>>> the driver communicating on interrupt endpoint i am not able to get
>>> performance more than 15Mbits/sec. However with the same device and
>>> application but driver from "thesycon" i.e. USBIO, performance is
>>> about 80Mbits/sec.
>>>
>>> Can some one tell why ? or if someone has the performance figures of
>>> bulkusb.sys or if some can guide how to improve the performance.
>>>
>>> Regards,
>>
>>
>

xxx
Thu Jan 31 21:41:12 CST 2008

Thanks everyone for the inputs, I will try them and get back

xxx
Thu Jan 31 21:51:57 CST 2008

please clarify this also

>>
2) so this WriteFile() i am requesting 50K bytes to be written, hence
there is always data to be sent. Hence driver should load bus, but i
see in CATC that between two SOF only single packet of 512 is sent.
>>

Why is sending of 50 , 1K packets ( i.e. pending multiple URB) more
efficient than sending just one 50K packet to bulkusb.sys driver

Alexander
Thu Jan 31 23:37:24 CST 2008

Neither is efficient.
The best would be sending reasonable number (8-16) of reasonable-sized
requests (64-256 KB).

You want to keep USB busy, this is why you need to have several requests
pending, while at the same time you want to reduce fixed overhead per
request. And usually you won't get more than one requests per microframe, or
maybe even per frame. Thus, the requests need to be reasonable large.

"xxx" <anshul.solanki@gmail.com> wrote in message
news:55690f49-1c59-4d16-a99b-afc7a371ebcc@j78g2000hsd.googlegroups.com...
> please clarify this also
>
>>>
> 2) so this WriteFile() i am requesting 50K bytes to be written, hence
> there is always data to be sent. Hence driver should load bus, but i
> see in CATC that between two SOF only single packet of 512 is sent.
>>>
>
> Why is sending of 50 , 1K packets ( i.e. pending multiple URB) more
> efficient than sending just one 50K packet to bulkusb.sys driver

Tim
Sat Feb 02 16:29:41 CST 2008

xxx <anshul.solanki@gmail.com> wrote:

>please clarify this also
>
>>>
>2) so this WriteFile() i am requesting 50K bytes to be written, hence
>there is always data to be sent. Hence driver should load bus, but i
>see in CATC that between two SOF only single packet of 512 is sent.
>>>
>
>Why is sending of 50 , 1K packets ( i.e. pending multiple URB) more
>efficient than sending just one 50K packet to bulkusb.sys driver

What you send to bulkusb.sys is not so important. What is important is
what bulkusb.sys sends to the host controller. Remember that USB is a
"scheduled" bus: the host controller schedules all of the transactions in
advance, and the transactions get committed once the frame starts.

When you send down a single 50K read, that gets chopped into 97 USB
requests of 512 bytes each. That will just about fill one frame (8
microframes, 1 millisecond). The host controller will schedule them out
across one frame.

But by the time that request finishes, the host controller is already
scheduling the NEXT frame. If you don't have another request waiting in
the wings, you won't get a shot. The frame will go on without you, and you
will lose an entire millisecond.

Also, if your hardware should ever send a short packet (less than 512
bytes), the entire 50k transfer will be completed back to you. Again,
unless you have another request already waiting, you will miss the rest of
that frame.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.