02-25-2009 03:05 PM
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
Solved! Go to Solution.
02-27-2009 02:05 AM
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
LOA | |
2 | |
den 26 februari 2009 | |
10:27:43 | |
administrator | |
3.0816786 seconds | |
3 | |
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
02-27-2009 03:06 AM
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
02-27-2009 03:37 AM
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
02-27-2009 09:35 AM - edited 02-27-2009 09:36 AM
02-27-2009 04:17 PM
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
02-27-2009 07:26 PM - edited 02-27-2009 07:27 PM
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
02-27-2009 08:59 PM
Found a link from an msdn blog related to this issue: http://blogs.msdn.com/oldnewthing/archive/2008/09/08/8931563.aspx
-Doug
02-27-2009 10:02 PM
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
02-28-2009 02:08 AM
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