Windows 中进程的最短保证时间是多少? [英] What is the minimum guaranteed time for a process in windows?

问题描述

我有一个进程可以提供具有特定缓冲区大小的硬件(数据传输设备).我可以从 Windows 调度程序窗口中合理地期望什么来确保我不会出现缓冲区下溢?

I have a process that feeds a piece of hardware (data transmission device) with a specific buffer size. What can I reasonable expect from the windows scheduler windows to ensure I do not get a buffer underflow?

我的缓冲区大小为 32K，每秒消耗约 800k 字节.

My buffer is 32K in size and gets consumed at ~800k bytes per second.

如果我以 16k 字节的批次填充它，即每 20 毫秒一批.但是，我填充它的下限是多少.如果说，我在填充循环中调用 sleep(0) 是我合理的最坏情况调度间隔是多少?

If I fill it in 16k byte batches that is one batch every 20ms. However, what is my lower limit for filling it. If say, I call sleep(0) in my filling loop what is my reasonable worst case scheduling interval?

操作系统 = Windows XP SP3双核 2.2Ghz

OS = Windows XP SP3 Dual Core 2.2Ghz

注意，我正在调用 API 来检查缓冲区填充水平，并调用驱动程序 API 以将数据传递给它.我假设这些是 Windows 除了 sleep(0) 之外还可以使用的调度点.

Note, I am making an API call to check the buffer fill level and a call to the driver API to pass it the data. I am assuming these are scheduling points that Windows could make use of in addition to the sleep(0).

我想(作为一个过程)表现得很好，并且仍然满足我的实时截止日期.机器专用于此任务，但需要通过网络接收数据并将其发送到 IO 设备.

I would like to (as a process) play nice and still meet my realtime deadline. The machine is dedicated to this task but needs to receive the data over the network and send it to the IO device.

我对调度程序性能有什么期望?我还需要考虑什么.

What can I expect for scheduler perfomance? What else do I need to take into account.

推荐答案

没有保证的最坏情况.失去 CPU 数百毫秒是很有可能的.无论内核线程在做什么，您都受制于它们，它们总是以比您所能获得的更高的优先级运行.遇到行为不端的 NIC、USB 或音频驱动程序是您将经常遇到的问题.除非你能控制硬件.

There is no guaranteed worst-case. Losing the CPU for hundreds of milliseconds is quite possible. You are subject to whatever kernel threads are doing, they'll always run with a higher priority than you can ever get. Running into a misbehaving NIC, USB or audio driver is a problem you'll constantly be fighting. Unless you can control the hardware.

如果您可以在偶尔的运行不足情况下幸免于难，那么请确保您用来获取设备数据的 I/O 请求是一个可等待事件.Windows 喜欢调度阻塞在所有其他请求之前完成的 I/O 请求的线程.使用 Sleep() 进行轮询不是一个好策略.它会不必要地消耗 CPU 周期，并且调度程序根本不会支持线程.

If you can survive occasional under-runs then make sure that the I/O request you use to get the device data is a waitable event. Windows likes scheduling threads that are blocking on an I/O request that completed ahead of all other ones. Polling with a Sleep() is not a good strategy. It burns CPU cycles needlessly and the scheduler won't favor the thread at all.

如果您无法在运行不足的情况下幸存下来，那么您需要考虑使用设备驱动程序.

If you can't survive the under-runs then you need to consider a device driver.

这篇关于Windows 中进程的最短保证时间是多少?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！