High-resolution timestamps in SmartInspect

Tobias Gurock

Thanks for the comment, Davy. The problem with the multimedia timers is their maximum resolution of 1ms. This is unfortunately not a lot better than the resolution provided by the standard system timers.

I’ve read about the leaping forward problem before. It is unfortunate but not that problematic if the time occasionally advances by a second or two on some hardware under certain circumstances. What’s indeed more problematic are the multi-processor related problems. I’ve spent the last hours reading articles/documentation about this issue and although the QPC function tries to do its best, it seems that hardware related bugs can still cause some problems here. Microsoft recommends to call QPC from a single thread which is ideally configured to run on a single processor only:

http://msdn2.microsoft.com/en-us/library/bb173458.aspx

This is unfortunately not an option for us since we can not change the threading behavior of the host application just for a logging library. However, small jumps in time related to multi-processor synchronization problems/bugs are acceptable to a certain degree but obviously not if these jumps are backwards. But a simple work-around like comparing the return value of QPC with the previous counter value could at least guarantee that the time cannot go backwards.

But I’ve found another problem in the meantime. It is related to CPUs with varying frequencies like found in most modern notebooks. With these kinds of processors it can happen that the QPC return values can get totally inaccurate. Internally, on some systems QPC can use the RDTSC instruction which increments a counter on every CPU clock cycle. If the underlying hardware uses some mechanisms to adjust the CPU frequency dynamically depending on the machine load (like Intel’s SpeedStep technology), it can happen that QPC and QPF can produce wrong results:

http://www.codinghorror.com/blog/archives/000460.html
http://www.gamedev.net/reference/programming/features/timing/

I haven’t seen this myself while testing, but it’s plausible. What’s interesting is that I’ve also found references stating that QPC and QPF can understand and handle SpeedStep and similar technologies under some circumstances. However, even if this is true, this whole discussion makes QPC obviously a less reliable option. What I will test is to improve my existing code by adding some detection code which can fall back to the standard system timers (or maybe the multimedia timers) when such a problem is found.

With all the found problems, we will probably disable high-resolution timestamp support by default and add more documentation to our manual. We already added some topics about this new feature, but I think it’s a good idea to add more details about the impacts and potential problems of high-resolution timestamps and the QPC usage.

Tobias Gurock

There are even more problems related to QPC (clock synchronization and deviation over time). I’ve found an interesting article from the MSDN Magazine:

http://msdn.microsoft.com/msdnmag/issues/04/03/HighResolutionTimer/

We decided to disable high-resolution timestamps by default and declare it as ‘developer-only’ feature, i.e. intended for use during development and not on production systems. It’s still a very nice feature, but the problems unfortunately make it unsuitable for production usage.

Multimedia timers look indeed more interesting now, but I’ve read about performance problems if you use the maximum possible resolution (about 1ms). The default resolution of the multimedia timers is about 5ms on Windows 2000 and later whereas the standard system timers can provide 15ms (and even 10ms on Windows NT). On older Windows versions, the difference between multimedia and standard timers is more noticeable though. It’s probably a good idea to think about adding an additional option in the future for using multimedia timers.

Tobias Gurock

Hi Roland,

We need to do some further testing before we can release this feature to the public. But this new feature will definitely be integrated into the next minor version (SmartInspect 2.2).