将代码移动到内核空间会给出更精确的计时吗？

Question

背景资料：

我目前有一个硬件设备，连接到USB端口。硬件设备负责向各种网络发送精确的周期性消息，而这些网络也是它所连接的。在硬件设备中，我有几个微芯片dsPIC。有两种运作方式。

其中一种情况是，将简单的“作业”发送到dsPIC，而dsPIC又可以准确地发送具有.001ms准确性的消息。对于更复杂的消息传递来说，这种架构并不理想，因为我们需要根据PC应用程序中正在发生的事件发送一个周期性的数据包。因此，我们有第二种操作模式，我们的PC应用程序将发送周期性消息，而dsPIC只是响应地转换和传输。顺便说一句，所有这些对我们软件的最终用户来说都是透明的。我们的硬件设备是一个测试工具，用于汽车领域。

目前，我们使用的是来自FTDI的USB到串行芯片，以及FTDI Windows驱动程序来将硬件与我们的PC软件接口。

问题是，在模式2中，我们从PC发送消息，我们能够达到的最好的是在平均硬件范围大约1ms。我们受到Windows内核的抢占.我尝试了一些“技巧”来改进一些事情，比如：

确保我们的读写器线程生活在独立的CPU亲缘上，当possible.

• Increasing是写入器的线程优先级时，同时减少reader.

• Informing的线程优先级，用户在使用software.

• Replacing创建线程调用时关闭屏幕保护程序和其他应用程序。

我们所有的软件都是用C/C++编写的。我非常熟悉和适应先进的Windows编程；例如IO完成、重叠I/O、无锁线程队列(实际上是一种设计策略)、套接字、线程、信号量等。

但是，我对Windows驱动程序的开发一无所知。我读过几篇关于KMDF与UDMF和WDM的论文。

我希望一个经验丰富的Windows内核模式驱动程序开发人员能在这里做出回应.

下一个版本的硬件可以选择替换FTDI芯片，并使用dsPIC的USB接口，或者，可能的话，将开源的Linux FTDI组件移植到Windows，并在我们的自定义驱动程序中继续使用FTDI芯片。我认为，通过访问PC端的内核模式驱动程序，我可以建立一个内核驱动程序，它可以以更精确的间隔发送周期性消息，而不需要抢占和/或可能利用DMA。

我们有一个竞争对手在我们的业务，我认为谁做了完全类似的东西，他们的工具。据我所知，用户空间应用程序调度线程的时间不能超过1ms。我们目前在线程中使用timeGetTime。我体验过计时器队列(通过CreateTimerQueueTimer)，没有真正的改进。

波分复用是实现更精确定时的正确方法吗？

我们的竞争对手如何实现非常精确的时间从Windows驱动信号到他们的硬件，他们确实加载了一个内核驱动程序(.sys)，他们的设备运行USB2.0和我们的一样。

如果WDM是要走的路，我能得到一些建议吗?我应该研究哪些内核函数来设置时间？谢谢你的阅读

Answer 1

在内核模式下，您可以在不处理中断的情况下以100纳秒间隔的倍数触发DPC。DPC不能被抢占(也就是被线程调度程序中断)，因为线程调度器也是DPC。不过，中断仍然可以抢占DPC。因此，间隔期值为10应该可以使您有一个非常精确的回调。

但是，您无法访问许多特性，例如分页内存，或DPC级别的特定线程的内存空间，因为它们在任意上下文中运行。使用能够访问更多功能的APC将处理推迟到您自己的用户模式进程的上下文中可能是有用的。

内核线程在优先级方面没有得到任何特殊的处理。从调度器的角度来看，它们与用户线程是相同的。内核线程可以获得更多更高优先级的级别，但通常没有内核线程使用其中的任何一个。我不认为您的瓶颈是线程优先级。不管你的优先级有多大，只要比其他人多一，就足以让你成为获得最高优先级的“神线”。拥有最高优先级并不意味着你会得到持续的关注。OS仍然会暂停您的线程来运行其他线程，这样就不会发生量子饥饿。

关于Windows抢占行为的另一个注意事项:当一个线程被异步事件(GUI单击、计时器触发器、I/O完成)发出信号时，Balance Set Manager会临时提高线程的优先级，以允许完成代码以更少的抢占完成它的处理。使用异步计时器处理程序应该可以提供足够的提升，以防止抢占，至少对于量程而言是这样。我想知道为什么您的代码没有掉进那个窗口。然而，似乎你不是唯一一个在计时器精度方面有问题的人：http://www.virtualdub.org/blog/pivot/entry.php?id=272

我同意Paul关于驱动程序开发的复杂性，但是只要你有充分的理由，这不是火箭科学，只是更多的努力。

Answer 2

这是Windows内核的基本设计方面之一--运行在被动级别上的代码(=>所有用户模式代码)受DPCs和中断占用时间的限制，如果您想获得1U的精度，您可能不会使用UMDF或用户模式驱动程序来获得它。

然而，编写内核驱动程序并不是一项简单而廉价的工作，它非常困难，甚至很难编写，也很难确保它在客户的计算机上工作(需要测试的)。把它做好将花费你大量的工程资源。

作为权宜之计，我想看看MMCSSfor>= Vista (http://msdn.microsoft.com/en-us/library/windows/desktop/ms684247(v=vs.85).aspx)，它可能给您足够的优先级，您可以满意。

如果你真的想去兔子洞，KMDF就是你应该使用的东西。KMDF是WDM之上的一个框架，它代表了许多编码好的驱动程序最佳实践。除非你是绝对被迫的，KMDF是总是是最好的方法去驱动。老实说，你几乎肯定会想要与OSR (http://www.osr.com)签订合同，或者雇佣一个人(几个人？)有编写Windows驱动程序的经验。

Answer 3

您对驱动程序和内核性能的关注忽略了树的林。房间里的大象是一个事实，全速USB 2总线帧发生在1ms周期内。高速USB 2微型帧每隔1/8ms发生一次。

当您通过全速USB发送数据时(就像大多数FTDI芯片一样)，您的应用程序所希望的最好的结果就是在下一个帧中的某个时候数据将到达设备。在卸载USB总线的情况下，传输将非常接近帧的起始点.您将观察到它的粒度为1ms，且具有小的随机偏差。这正是你所看到的，而且还不错。例如，由于连接到同一主机上的所有USB设备将同时看到帧，这是一种以比微秒精度更好的方式同步多个设备时钟的简单方法。您的应用程序所能做的只是发送一条消息，该消息不仅包含数据，而且在不久的将来应该发送出去。USB的另一个问题是，您的数据传输请求将在什么时候得到服务，这是没有保证的。毕竟，你和其他设备共用一辆公共汽车。

我认为您需要重新设计您的系统，而不是依赖于任何类型的时间从PC端。在PC上运行的应用程序应该被假定为时间上的应用，仅限于与其交互的人的性能。任何需要保证实时性能的东西都必须在您的dsPIC设备上。即使是USB总线也没有削减它，因为你没有任何保证，在多长时间内，您的请求将安排在总线上。

基本上，如果您想要保证Windows上的实时性能，那么必须不涉及任何用户模式--所有这些都必须在内核模式下运行，并且您必须使用专用的通信通道(或者让它们以这种方式运行，例如在USB主机上进行过滤)。