12-17-2009 01:02 PM
I installed latest TestStand (v4.2.1) on a Quad Core PC (Intel Core2 Quad CPU, Q9400 @ 2.66GHz), but I am noticing the same problem. The computer is up to date in terms of Windows update as well.
I found some topics on the web about the pmtimer issue. But, before I make the change in boot.ini on the new computer, I wanted to check if:
1) Intel processors have the same problem?
2) Can changing to PM Timer have any side effects on performance?
http://kb.mozillazine.org/Timeout_on_dual_core
http://blogs.msdn.com/tvoellm/archive/2008/06/05/negative-ping-times-in-windows-vm-s-whats-up.aspx
Are future releases of TestStand planned to workaround this issue?
Thanks!
09-07-2016 07:27 AM
Am I right to assume that TestStand 2012 and 2014 also use the PerformanceTimer API?
I am getting interesting effects on different machines that the execution time of a Wait(0.01) is anwyhere between 10.5 and 18ms, relatively stable on each machine, but different between machines.
I am measuring the time by using a logging library which also logs the values of the PerformanceTimer ...
Best regards
Peter
09-07-2016 08:16 AM - edited 09-07-2016 08:20 AM
The wait step does not use QueryPerformanceCounter when waiting on a time interval, and thus is limited by the system clock's resolution. TestStand does use QueryPerformanceCounter in other places though, such as Engine.SecondsSinceStart and related APIs.
Hope this helps,
-Doug
09-07-2016 08:24 AM
Actually, in looking at things more carefully, the wait step does use QueryPerformanceCounter in that it calls Engine.SecondsExecuting and other engine APIs to determine if the timeout has expired since it takes things into account like not counting the time the execution was paused at a breakpoint. However, the wait step also calls Sleep() to give up CPU time and the Sleep() api is subject to the resolution of the system clock.
Hope this helps clarify things,
-Doug
09-07-2016 08:28 AM
Yes, thank you, that clarifies it.
I originally assumed the Wait step to use Sleep() for giving up CPU time and then was a little confused as waiting for a PerformanceTimer value should both be more accurate and a lot more busy.
Thanks
Peter