What is the minimum guaranteed time for a process in windows?

Question

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?

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

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?

OS = Windows XP SP3 Dual Core 2.2Ghz

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).

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.

Answer 1

What is the minimum guaranteed time for a process in windows?

There is no guarantee: Windows is not a real-time O/S.

What else do I need to take into account

• What else is running on the machine (something high priority might preempt you)
• How much RAM you have (system performance changes a lot when RAM is in short supply)
• Whether you're dong I/O (because you might e.g. stall while waiting for disk or network access)

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.

Consider setting the priority of your process and/or thread at "real time priority".

Answer 2

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.

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.