Can the .NET Stopwatch class be THIS terrible?

Question

I\'m making an application that needs some pretty tight timing, and the Stopwatch class is the perfect solution. However, I noticed sometimes, when running on a small panel

Answer 1

Exact timing on PC hardware isn't straightforward, period. Here are some resources, showing some experiences with timing in Windows, which will be the underlying implementation of any counter in a Windows environment, including .NET:

• Results of some quick research on timing in Win32
• Need help with QueryPerformanceCounter and Dual Processors

It explains why sometimes you will get 10 ms resolution, depending on which system call you use, and sheds a little more light on why QueryPerformanceCounter is "buggy". One of the points made is that power saving modes/variable CPU speeds can interfere with these timings.

A related concept to this is "locking the timestep" in real-time physical simulations. If you google for that, you may get some ideas on how to work around problems you are having. The basic concept is that you have fixed time steps, and do a sort of producer/consumer implementation for your timing/update functions. I don't know if this applies to your specific domain, but it is considered a best-practices in video games.

Answer 2

Update (after seeing your log)

As you already mentioned, the Stopwatch class uses the QueryPerformanceCounter function underneath. In the Remarks section MSDN says:

On a multiprocessor computer, it should not matter which processor is called. However, you can get different results on different processors due to bugs in the basic input/output system (BIOS) or the hardware abstraction layer (HAL). To specify processor affinity for a thread, use the SetThreadAffinityMask function.

As you are using the Dispatcher, QueryPerformanceCounter might not be executed on the same CPU every time that you query the elapsed time.

You can possibly check if the issue mentioned in MSDN is the reason for your problem by specifying a processor affinity for your process, e.g. by calling your executable using the start command. 10 seconds seems like a big lag between CPUs to me, but the documentation is very vague on how big the difference may be. The following command will bind your application to the first CPU:

> start.exe /AFFINITY 1 program.exe

If this should solve the issue you might want to have a look at the suggested workaround, i.e. calling the SetThreadAffinityMask function before querying the Stopwatch object.

Your comment said that you are using a WPF DispatcherTimer. The documentation of that class states:

Timers are not guaranteed to execute exactly when the time interval occurs, but they are guaranteed to not execute before the time interval occurs. This is because DispatcherTimer operations are placed on the Dispatcher queue like other operations. When the DispatcherTimer operation executes is dependent on the other jobs in the queue and their priorities.

This means that the timer event may arrive delayed, especially if the dispatcher is busy with other tasks. Did you place other things in the dispatcher queue that will prevent the event from triggering earlier?

Answer 3

Perhaps I am misunderstanding your question, but do you need to just measure time intervals or do you need to execute code at those intervals? If you need to execute code, then check out System.Timers.Timer class as it is thread safe and should work fine for multi-processors.