自动 DPC 延迟测试 - 如何进行？
对于实时多媒体任务，低延迟至关重要。例如，稳定的低延迟值使得可以使用计算机来制作音乐。
据我所知，Windows系统下有一个DPC延迟的东西，对于保证延迟的稳定性是非常关键的。您可以在此处阅读有关延迟过程调用的更多信息：http://en.wikipedia.org/wiki/Deferred_Procedure_Call。
正如您在 Thescyon 网站 上看到的那样，
如果 Windows 系统中的任何内核模式设备驱动程序实施不正确，并导致延迟过程调用 (DPC) 延迟过大，那么当您使用实时音频或视频流应用程序时，可能会发生丢失。
他们提供了一个简单的工具来检查这一点，并绘制延迟图。当您想要测试 Windows 计算机的专业音频时，您应该运行此 DPC 延迟检查器并强调可能导致问题的组件。例如，当我测试笔记本电脑时，我会检查当您
- 打开无线开关或使用无线连接、
- 将存储卡插入读卡器、
- 调整屏幕亮度时，延迟会发生什么情况（与 ACPI 相关的事情可能会导致真正的延迟）。混乱...）
等等。
我的问题是，如果我想自动检查以上内容该怎么办？ 我想开发一个可以测试这一点并生成报告的工具，这样我们就可以在短时间内测试大量配置。 （我的问题：我不知道如何测量 DPC 延迟以及如何通过代码自动控制亮度等。）
背景：我买了一台笔记本电脑，它应该非常适合制作音乐 - 但事实并非如此，因为它产生几乎不合理的延迟问题。事实上，我已经咨询 Focusrite 支持几个月了，但我们无法解决问题。所以我想通过创建一个易于使用的测试工具来帮助音乐家进行选择，该工具可以清楚地表明计算机是否正常。或者更好的是，创建一个包含 DPC 延迟信息的最新公共数据库。
请支持此问题以提高 DPC 意识 - 我们确实需要让制造商知道这对任何人来说都是一个真正的问题对 Windows 系统上的多媒体感兴趣。
For real-time multimedia tasks the low latency is essential. A stable low latency value makes it possible to use a computer for making music for example.
As far as I know, under Windows systems there's a DPC latency thing that's quite crucial for ensuring the stability of the latency. You can read more about Deferred Procedure Calls here: http://en.wikipedia.org/wiki/Deferred_Procedure_Call.
As you can read on the Thescyon website,
If any kernel-mode device driver in your Windows system is implemented improperly and causes excessive latencies of Deferred Procedure Calls (DPCs) then probably drop-outs will occur when you use real-time audio or video streaming applications.
They provide a simple tool for checking this which draws a latency graph. When you want to test a Windows computer for pro audio, you should run this DPC latency checker and stress the components that could cause problems. For example when I'm testing laptops, I check what happens with the latency when you
- switch the wireless on-off or use a wireless connection
- insert a memory card into a card reader
- adjust the screen brightness (ACPI-related things can cause a real mess...)
and so on.
My question is, what should I do if I want to check the above automatically?
I would like to develop a tool which could test this and generate a report, so we could test a lot of configurations in a short time. (My problems: I don't know how to measure DPC latency and how to automate brightness controlling from code etc.)
Background: I bought a laptop that should be fairly ideal for making music - but it's not, since it produces almost irrational latency problems. In fact, I've consulted with the Focusrite support for months and we weren't able to solve the problem. So I want to help musicians in choosing by creating an easy-to-use testing tool which could clearly says if a computer is okay. Or the better, to create an up-to-date public database with DPC latency informations.
Please support this question to raise DPC awareness - we do need to let manufacturers know that this is a real issue for anyone interested in multimedia on Windows systems.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您的问题有几个问题。
首先，您无法真正检查 DPC 延迟。您可以将自己的 DPC 排队，然后检查其执行时间。或者您可以查询所有 DPC 的运行时间（我不知道您是否有相关的性能计数器信息，或者是否必须进行基于样本的分析）。
即使您有这些信息，它也是针对您所处情况的。此外，还有一些随机因素会导致数字出现偏差。
DPC 排队到全局 DPC 队列中，并且可以在任何处理器上运行。因此，如果您确实在一个核心上有一个长时间（运行）的 DPC，则另一个核心可以自由地处理另一个核心。因此，任何计时信息实际上都取决于您拥有的处理器数量以及当前同时执行的事物数量。因此，在多核处理器上，这些数字可能会有很大差异。
即使您拥有有关一种用例的信息，这也很大程度上取决于系统的当前情况。当它连接到（大型）网络时，可能会为您的计算机接收的网络数据包引发很多小型 DPC。当您拔掉计算机电源（或每个人都回家）时，这场 DPC 风暴突然停止。
注意：当您拥有一台新计算机时，您的 DPC 延迟问题可能源于处理器休眠的 c 状态。Core-iX 处理器确实很快进入休眠状态，但从休眠状态唤醒的速度却非常慢。
There are several problems with your Question.
First of all, you cannot really check the DPC latency. You either can queue an own DPC and then check when its executed. Or you can query the time a/all DPCs run (I don't know if you have performance counter information for that, or if have to do sample based profiling).
Even if you have this information, it is very specific to the situation you are in. Furthermore there are several random factors which skew numbers.
A DPC is queued into the global DPC queue, and can be run on any processor. So if you really have a long (-running) DPC on one core, the other core is free to process another. So any timing information is really dependent on the count of processors you have and how many things get currently executed concurrently. So on multicore processors these numbers might vary widely.
Even when you have information about one use case, this is very dependent on the current situation of the system. When its connected to a (large) network, there may be very many small DPCs raised for the network packets that are received by your computer. When you unplug your computer (or everyone goes home) this DPC storm suddenly stops.
NB: When you have a new computer, your DPC latency problem may derive from the c-states your processor sleeps in. The Core-iX processors do really fast into a sleep state from which they wake really slowly.
也可以看看http://www.resplendence.com/latencymon，因为它有帮助更好地定位问题的根源。
正如另一个答案中所述，现代 CPU 使用多种复杂的技术，即不同的 c 状态和超线程。
Also have a look at http://www.resplendence.com/latencymon as well, as it helps better with locating the source of the issues.
As stated in the other answer, modern CPU's use several complicating technologies, namely the diverse c-states and also hyperthreading.