NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Wrong Wait() step execution time

Solved!
Go to solution

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!

 

0 Kudos
Message 11 of 15
(1,709 Views)

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

0 Kudos
Message 12 of 15
(1,306 Views)

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

0 Kudos
Message 13 of 15
(1,302 Views)

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

Message 14 of 15
(1,296 Views)

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

 

0 Kudos
Message 15 of 15
(1,293 Views)