Wrong Wait() step execution time

[Anders_Swe]

Hello

I have a very strange problem. We still use TestStand 3.1 for our production tests and we currently run TestStand on 12 different test stations.

I just got a new nootbook which I use for development of tests but now I have a very strange problem. When I run tests with a Wait() step the execution

time for this step takes 3-5 times longer than the amount of seconds I have set into the expression. For instance if I make a sequence containing only one

step Wait(5) it should take about 5 seconds to execute but it takes 15 to 25 seconds to execute!! And to make it more strange, in the report the execution time

shows 5,1 seconds? All other steps I run executes in a normal execution speed, my own or standard step types (at least what I have found out so far).

I have had TestStand installed on my older notebook without problems. I have tested both on XP with and without SP3, but no luck!

I now have to find out if it is TestStand or my notebook that causes this problem, it is not easy to explain this problem for the people a HP. What clock does the

Wait function use and could I make a debug sequence that could give me more information regarding my problem.

I have now reinstalled my notebook 3 times and reinstalled TestStand 6 times so I'm getting desperate, anybody how could give me some ideas what could cause this problem.

Regards

Anders 

[Anders_Swe]

Hello Again

I now tested to install an evaluation copy of TestStand 4.1 and I get the same result. I have now made a little test sequence where I first ask for the system time Time() and then Wait(3) and finally ask for system time again. You can see the result below:

The computer specs:

HP 8530p with T9400

Windows XP SP3 (have tested with and without SP3, doesn't make any difference)

2 GB memory

UUT Report

Station ID:	LOA
Serial Number:	2
Date:	den 26 februari 2009
Time:	10:27:43
Operator:	administrator
Execution Time:	3.0816786 seconds
Number of Results:	3
UUT Result:	Passed

---

Begin Sequence: MainSequence
(C:\Program\National Instruments\TestStand 3.1\Sequence File1.seq)

Get Start Time
Status:	Done
Start Time: 10:27:43
Wait 3 seconds
Status:	Done
Statement
Status:	Done
End Time: 10:30:33

End Sequence: MainSequence

 

 

[RayFarmer]

Hi,

Not sure I see your problem. You have waited 3 secs and your overall execution time is just a little over 3 secs. So where is the problem.

Regards

Ray Farmer

[Norbert_B]

Could you post your sequence file?

I am interested in how you took the timestamp. As Ray said, the execution in TestStand was a little more than 3s, but the timestamps impresses a little less than 3m. That is definetly something odd and i have never encountered something like this....

Norbert 

[Erik_Crank]

Sounds like the same problem as this thread: http://forums.ni.com/ni/board/message?board.id=330&thread.id=21123

Message Edited by Erik Crank on 02-27-2009 09:36 AM

[Anders_Swe]

OK, a little update of todays debugging

I have run my test sequence on both TS 3.1 and 4.1 and I get the same error. 

I started to suspect that the problem has something top do with the Speedstep function on my computer. When my notebook is in idle it runs at 1,6 GHz and during load 2,53 GHz. I started a program called CPU-Z where you can see the current speed mode and then I was running my debug sequence that contains two steps: first I call the function Seconds() and then a Wait() step. If I only run the first Seconds() step and loop it indefinetly the CPU speed is at max and the the result from seconds step counts seconds at a 'normal' rate. If I however also includes the second step in my loop with a Wait(0.1) the CPU speed starts jumping between 1,6 to 2,53 GHz and the seconds step shows 'slow' counting (I hope you understand this). So during my last discussion with NI support we tested my theory by starting a disk defragmentation in the background which causes my cpu to run at max speed and then run the initial test the Wait(3) step finally waits only three seconds!!

The Speedstep function on my notebook is the problem and causes the Wait() step to calculate time wrong.

Unfortenately HP has a braindead BIOS where it is not possible to turn off this Speedstep function (in normal BIOS:es this can be done).

My old notebook did also have a CPU (T7400) with Speedstep and I did not have this problem on that computer so it must have something to do with the newer chipset or so. The HP support can't (or don't care) to help me so I now hope that NI can solve this problem. For a quick fix I have made simple LabVIEW application that stresses my CPU and I run it in the background when I am running my tests 🙂

There can be issues with TestStand and newer notebooks, mine is a HP 8530p T9400 with PM45 chipset.

Thanks for your input

Anders 

[dug9000]

The Windows SDK functions we are using underneath are QueryPerformanceCounter and QueryPerformanceFrequency. According to Microsoft's documentation for QueryPerformanceFrequency, the frequency cannot change while the system is running. Either Microsoft's documentation is incorrect or the hardware is violating this requirement. Also according to Microsoft's documentation for QueryPerformanceCounter, bugs in the BIOS or HAL have been known to lead to issues with this API.

Thanks for figuring out that this is related to SpeedStep on some machines. We will look into this more and let you know what we discover.

Microsoft's documentation for these APIs:

http://msdn.microsoft.com/en-us/library/ms644905(VS.85).aspx

http://msdn.microsoft.com/en-us/library/ms644904.aspx

Hope this helps,

-Doug

Message Edited by dug9000 on 02-27-2009 07:27 PM

[dug9000]

Found a link from an msdn blog related to this issue: http://blogs.msdn.com/oldnewthing/archive/2008/09/08/8931563.aspx

-Doug

[dug9000 · Accepted solution]

Although this article talks about a bug related to an AMD CPU and your machine has an intel CPU, perhaps the workaround that it contains might still work. I think it switches the machine to use a different hardware timer by adding the /usepmtimer flag to the boot.ini file.

http://support.microsoft.com/kb/895980

This links makes it sound like the problem or a similar problem also can or did occur with intel hyperthreaded or enhanced speed step systems and the same boot.ini workaround of using /usepmtimer is one of the options suggested.

http://support.microsoft.com/kb/835730

I'm not sure how safe it is to try this workaround though so I understand if you'd rather not. I'd certainly recommend backing up everything you have that's important before attempting the boot.ini changes incase it ends up making the machine unbootable. If you do end up trying this workaround please let us know how it goes.

Thanks,

-Doug

[Anders_Swe]

Hello!

dug9000, you are my hero!

I followed the instructions in http://support.microsoft.com/kb/895980 and it solved my problem. I added /usepmtimer in my boot.ini file and now my Wait() function

works as it should.

Thanks for all help

Regards

Anders