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.