We developed a driver for a USB bulk-transfer device using UMDF (WinUSB). We found that our new UMDF driver is about 25% percent slower (for small bulk read/write transfers of up to 512K bytes with typical transfers around 1K bytes or less) compared to the corresponding WDM driver for the same device. In trying to isolate the problem, we found that the WinUSB service (specifically WudfHost.exe) is utilizing ~50% of the CPU! These performance measurements were taken on WinXP (we have not measured performance on Vista yet).
Has anyone noticed this performance degradation with UMDF drivers or know how to resolve it?
The best way to improve performance of a UMDF driver is to do more with each request. There’s unfortunately a fairly high fixed overhead for each request that goes over to the host, so if you can do one 512KB transfer instead of 512 1KB transfers you’ll get much better performance.
-p
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@intel.com
Sent: Thursday, May 01, 2008 12:24 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] UMDF driver performance
We developed a driver for a USB bulk-transfer device using UMDF (WinUSB). We found that our new UMDF driver is about 25% percent slower (for small bulk read/write transfers of up to 512K bytes with typical transfers around 1K bytes or less) compared to the corresponding WDM driver for the same device. In trying to isolate the problem, we found that the WinUSB service (specifically WudfHost.exe) is utilizing ~50% of the CPU! These performance measurements were taken on WinXP (we have not measured performance on Vista yet).
Has anyone noticed this performance degradation with UMDF drivers or know how to resolve it?
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
For small request sizes - you mentioned typically 1k bytes - the UMDF overhead would be considerable which is likely causing drop in throughput and high CPU utilization.
UMDF overhead would not be significant at larger request sizes around 64k. If you can change the transfer size from the app, that should provide you significant improvement. You can still do small transfers from your UMDF driver if you really need to but application should send larger requests (since most UMDF overhead is in redirecting application request to the driver).
Asynchronous I/O from the app (although this may mean that you have to take care of ordering of packets in the driver), parallel queue in your UMDF driver, async I/O from your UMDF driver (this one would be automatically taken care of if you use USB I/O targets) would further enhance the perf, but request size from the app is likely to be the biggest factor.
Praveen
xxxxx@intel.com wrote:
Has anyone noticed this performance degradation with UMDF drivers
[vs. WDM driver, for small transfer sizes] or know how to resolve it?
Yes, same effect with our bulk driver. According to MS, when going from
WDM to UMDF (a) with UMDF/WinUSB you can saturate an USB2.0 connection,
but only with large transfers, and (b) for small transfer sizes, a
performance degradation of only 10-20% is actually a very good value.
For our driver, going to large transfers is not an option, and it also
needs to run on legacy OS versions that don’t have WDF support, so I
keep it as a WDM driver. To have it run on Vista64, we sign it with an
SPC from Globalsign. (The only caveat is not to use Signability, but
Inf2cat.)
HTH -H
>(b) for small transfer sizes, a performance degradation of only 10-20% is actually a very good value.
I won’t necessarily say that it is a good value but it is the cost of isolation. We will continue to look for perf improvements and optimizations in UMDF.
Praveen
Had the same results with WinUSB small size packets.
Managed to reach quite good speed with bigger ones.
-Barni
Praveen,
Any idea when we can expect performance optimizations in the UMDF framework from Microsoft? We like the new framework for development and driver stability, however this much performance degredation is a big worry. We don’t have many options for using a larger transfer size, as most of what we do are small transfers. Is there a high emphasis at Microsoft on these performance optimizations in UMDF? If so, when can we expect an update?
xxxxx@intel.com wrote:
Any idea when we can expect performance optimizations in the UMDF framework from Microsoft? We like the new framework for development and driver stability, however this much performance degredation is a big worry. We don’t have many options for using a larger transfer size, as most of what we do are small transfers. Is there a high emphasis at Microsoft on these performance optimizations in UMDF? If so, when can we expect an update?
I’m not sure what you are expecting, but don’t expect miracles. A big
chunk of the performance hit here is simply inherent in the design. You
have a user-mode component and a kernel-mode component that need to
cooperate closely. Every transition between the two is expensive. The
smaller the buffers, the more the transitions, and the higher the
overhead. It’s the nature of the beast.
If you need more performance than UMDF can supply, then I believe you
have little choice other than to migrate to KMDF.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.