Prev: get USBDSTATUS using KMDF
Next: Printer Driver hangs in installation on Vista
From: jdh28 on 10 Nov 2008 04:19
"Tim Roberts" wrote:

> jdh28 <jdh28(a)discussions.microsoft.com> wrote:

> >Thanks for the response. We need both raw throughput and low latency.

> Those two goals are, essentially, mutually exclusive in a USB device.
> To get maximum throughput on a bulk pipe, you MUST use large
> transfers, and have several transfers queued up at once. However,
> large transfers by their very nature increase the latency.
>
> Most people who say "we need raw throughput and low latency" have not
> really done the math to figure out what the real requirements are.
> Without real numbers, your goal cannot be achieved.

This driver is for the second generation of a device that I wrote a WDM
driver for a number of years ago, so I am well aware of the limitations
of USB and what my requirements are.

> >UMDF does extra copying between kernel and user-space, and I just
> >want to check what the performance hit of this is.
>
> A maximum-throughput bulk pipe runs about 45 MB/sec. On today's
> typical processor, a memcpy of that magnitude is less than 0.5% CPU
> usage.

Maybe, but I wanted to actually measure the performance impact. I
managed to get a UMDF driver working with 1.5 (using the 6000 WDK), and
ran some tests with varying transfer sizes. The slowdown was only about
5% with very large transfers but was as great as 40% or 50% for smaller
transfers. I'll use KMDF I think.

Going back to my original issue, I made very similar changes to the UMDF
1.5 example and to the KMDF 1.7 example, with no problems. I'm thinking
that this is something I need to report as a bug.

regards,
John

From: Tim Roberts on 11 Nov 2008 01:16
jdh28 <jdh28(a)discussions.microsoft.com> wrote:
>
>Maybe, but I wanted to actually measure the performance impact. I
>managed to get a UMDF driver working with 1.5 (using the 6000 WDK), and
>ran some tests with varying transfer sizes. The slowdown was only about
>5% with very large transfers but was as great as 40% or 50% for smaller
>transfers.

For what it's worth, that pretty much matches what the WDF team has been
saying.
--
Tim Roberts, timr(a)probo.com
Providenza & Boekelheide, Inc.
From: Abhishek R [MSFT] on 18 Nov 2008 20:15
Hi John,
Will you be able to provide us with a crash dump? You can send it to
wdfinfo @ microsoft.com. A minidump may be enough to begin with.

Thanks,
Abhishek

"jdh28" <jdh28(a)discussions.microsoft.com> wrote in message
news:B000A1B5-B284-459E-BCD3-7149CF139EE4(a)microsoft.com...
> I'm looking at developing a driver for an FX2 based device and looking at
> the
> feasibility of using the UMDF. Performance is a concern for this driver,
> so I
> wanted to do a quick benchmark.
>
> I thought that the FX2 sample would be a good starting point, so I've
> taken
> that from the 6001.18002 WDK. My hardware has two alternate settings, so I
> added a call to pIUsbInterface->SelectSetting() in
> CMyDevice::CreateUsbIoTargets and tweaked the logic that selects the pipes
> and the device now correctly enumerates.
>
> However, if I unplug the device I get a BSOD, with the following stack
> trace:
> bacfb978 af9d170c 0000010d 00000005 76d5d5a0 nt!KeBugCheckEx+0x1b
> bacfb994 af9c7f0f 89180d48 00000005 76d5d5a0
> wdf01000!FxVerifierBugCheck+0x24
> bacfb9c0 af9ae879 89180d48 76d5d5a0 00001200
> wdf01000!FxObjectHandleGetPtr+0x71
> bacfb9ec b7697e85 89180e00 76d5d5a0 00000001
> wdf01000!imp_WdfIoTargetStop+0xc4
> bacfba18 af9f5902 00000050 00000005 afa11c30 WinUSB!WinUSB_D0Exit+0xb7
> bacfba38 af9f550b 89145c08 afa11900 89145c08
> wdf01000!FxPkgPnp::PowerGotoD3Stopped+0x14e
> bacfbab0 af9f6c97 00000314 00000000 89145c08
> wdf01000!FxPkgPnp::PowerEnterNewState+0x169
> bacfbad8 af9f7047 bacfbaf0 0000055b afa1357c
> wdf01000!FxPkgPnp::PowerProcessEventInner+0x22a
> bacfbafc af9fbe3a 00000001 bacfbb80 af9fc49a
> wdf01000!FxPkgPnp::PowerProcessEvent+0x20d
> bacfbb08 af9fc49a 89145c08 afa129e0 89145c08
> wdf01000!FxPkgPnp::PowerPolStopping+0x1a
> bacfbb80 af9fcff3 0000055b 00000000 89145c08
> wdf01000!FxPkgPnp::PowerPolicyEnterNewState+0x169
> bacfbba8 af9fd72f bacfbbc0 00000129 00000008
> wdf01000!FxPkgPnp::PowerPolicyProcessEventInner+0x21e
> bacfbbcc af9f8a29 00000001 bacfbc00 af9f9038
> wdf01000!FxPkgPnp::PowerPolicyProcessEvent+0x218
> bacfbbd8 af9f9038 89145c08 afa12270 89145c08
> wdf01000!FxPkgPnp::PnpEventFailedIoStarting+0x12
> bacfbc00 af9f9d8c 00000127 89145ca8 89145c08
> wdf01000!FxPkgPnp::PnpEnterNewState+0x15c
> bacfbc28 af9fa0b9 bacfbc40 89145c08 afa117a0
> wdf01000!FxPkgPnp::PnpProcessEventInner+0x1f5
> bacfbc50 af9f0b53 00000400 bacfbc68 af9f735d
> wdf01000!FxPkgPnp::PnpProcessEvent+0x1cf
> bacfbc5c af9f735d bacfbc88 bacfbc8c af9f1bcf
> wdf01000!FxPkgPnp::PnpSurpriseRemoval+0x29
> bacfbc68 af9f1bcf 89145c08 bacfbc88 891429f0
> wdf01000!FxPkgFdo::_PnpSurpriseRemoval+0x10
> bacfbc8c af9db665 891429f0 bacfbcb4 af9db888
> wdf01000!FxPkgPnp::Dispatch+0x2a6
> bacfbc98 af9db888 891d7110 891429f0 891429f0
> wdf01000!FxDevice::Dispatch+0x7f
> bacfbcb4 804ef19f 891d7110 891429f0 89317120
> wdf01000!FxDevice::DispatchWithLock+0x7b
> bacfbcc4 af9964bc 891429f0 89317120 00000000 nt!IopfCallDriver+0x31
> bacfbd0c af996264 89317120 af9a3300 af9a2e40
> wudfrd!RdPnpTracker::RdPnpProcessor+0x32e
> bacfbd54 af996673 89159c08 89429630 89e3b8b8
> wudfrd!RdPnpTracker::RdPnpProcessor+0xd6
> bacfbd68 80576ad5 89429630 89317120 8056485c
> wudfrd!RdPnpTracker::RdPnpCallbackAtPassiveInSystemProcess+0x43
> bacfbd7c 8053877d 89159c08 00000000 89e3b8b8 nt!IopProcessWorkItem+0x13
> bacfbdac 805cff70 89159c08 00000000 00000000 nt!ExpWorkerThread+0xef
> bacfbddc 805460ee 8053868e 00000001 00000000
> nt!PspSystemThreadStartup+0x34
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>
>
> Any ideas what I might be doing wrong?
>
> thanks,
> John

First  |  Prev  | 
Pages: 1 2
Prev: get USBDSTATUS using KMDF
Next: Printer Driver hangs in installation on Vista