如何提高 USB 设备驱动程序中的 Tx 性能？
我使用 Windows 驱动程序模型 (WDM) 在 Windows 2000 及更高版本上为 USB 1.1 设备开发了一个设备驱动程序。
我的问题是使用 64 字节批量传输时 Tx 性能非常糟糕。 根据所使用的 USB 主控制器，最大数据包吞吐量为每秒 1000 个数据包 (UHCI) 或 2000 个数据包 (OHCI)。 我在 Linux Kernel 2.6 上开发了一个类似的驱动程序，每秒处理大约 5000 个数据包。
Linux 驱动程序使用最多 10 个异步批量传输，而 Windows 驱动程序使用 1 个同步批量传输。 因此，比较这一点可以清楚地看出，虽然性能如此糟糕，但我已经尝试过异步批量传输，但没有成功（没有性能增益）。
有人有一些如何提高 Windows 性能的提示和技巧吗？
I developed a device driver for a USB 1.1 device onr Windows 2000 and later with Windows Driver Model (WDM).
My problem is the pretty bad Tx performance when using 64byte bulk transfers. Depending on the used USB Host Controller the maximum packet throughput is either 1000 packets (UHCI) or 2000 packets (OHCI) per seconds. I've developed a similar driver on Linux Kernel 2.6 with round about 5000 packets per second.
The Linux driver uses up to 10 asynchronous bulk transfer while the Windows driver uses 1 synchronous bulk transfer. So comparing this makes it clear while the performance is so bad, but I already tried with asynchronous bulk transfers as well without success (no performance gain).
Does anybody has some tips and tricks how to boost the performance on Windows?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我现在已经设法将发送速度加快到每秒约 6.6k 条消息。 解决方案非常简单，我只是实现了与 Linux 驱动程序中相同的机制。
所以现在我一次安排最多 20 个 URB，我应该说，它有效。
I've now managed it to speed up sending to about 6.6k messages/s. The solution was pretty simple, I've just implemented the same mechanism as in the Linux driver.
So now I'm scheduling up to 20 URBs at once, at what should I say, it worked.
您获得什么样的吞吐量？ USB 1.1 限制为大约 1.5 Mbit/s
这可能是您必须忍受的限制，您绝对不能做的一件事就是使系统资源匮乏。 我见过很多糟糕的驱动程序实现，其中驱动程序占用系统资源而完全无法提高其自身的性能。
我的猜测是您使用了错误的 API 调用，您是否查看过 Win32 DDK 中的 USB 示例？
What kind of throughput are you getting? USB 1.1 is limited to about 1.5 Mbit/s
It might be a limitation that you'll have to live with, the one thing you must never do is to starve the system for resources. I've seen so many poor driver implementations where the driver is hogging system resources in utter failure to increase its own performance.
My guess is that you're using the wrong API calls, have you looked at the USB samples in the Win32 DDK?