teststand and 64 bit OS

[david_jenkinson]

Hello,
We are running into memory limitations, because of long test runs that are 24+ hours.  When teststand memory usage grows due to the report results cluster getting very large, we get -17000 out of memory errors.

We have tried the "on the fly" and "conserve memory" options on the report and database options, but these options are undesirable for reasons that are lengthy to explain here (database related).

So my question is, if we were to upgrade to 64 bit windows (XP or Vista), would teststand run ok?  We are also using labview and NI vision (IMAQdx), would these work?  We are using TS 4.0 and LV 8.5, and the latest vision as well.

Thanks
David Jenkinson

[waldemar.hersacher]

Hello David,

there is a thread in the LV forum about 64 bit, http://forums.ni.com/ni/board/message?board.id=170&thread.id=309819. Just for one of the components you are using.

[RayFarmer]

Hi David,

I dont think changing to 64 bit OS would solve your problem, but just delay the point at which it runs out of memory.

What you need to do is reduce the amount of results you keep in memory. This may mean save out results to a file, then clearing the ResultList.

On-the-fly would be the way to go. Maybe you can do this for the Report logging but keep the Database logging as normal.

Regards

Ray Farmer

[david_jenkinson]

Hello Ray,
I was assuming the database reporting and html result reporting drew from the same result cluster.  If I do on the fly for reporting, but keep database logging on-the-fly off, will. there be any memory savings?

We have actually combed through our code quite a bit and turned off results reporting for everything that is not necessary.  We still have problems where the total memory usage creeps up to around 2.5gb after a 24 hour run, and we eventually want to run 72 hours.    So yes a 64-bit OS will just delay the effect, but hopefully will allow us to run for more extended periods.

Thanks

[James_Grey]

I haven't tried it, but perhaps this would help:

http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx

[dug9000]

One thing to note is that if you run teststand on a 64-bit machine it will still be running as a 32-bit application so will still be limited to a 32-bit address space.

Is this just one run of your test sequence that takes 24+ hours? TestStand frees up the result list after each run.

Is there some way you can periodically process the results at various points in your sequence? Not sure why on the fly will not work, if it could be made to work that would probably be your best option as it would also give you database logging throughout the sequence rather than all at the end so you wouldn't lose all your results if there was a power failure or other problems.

-Doug


Message Edited by dug9000 on 04-25-2008 10:46 AM

[david_jenkinson]

Hello Doug,
Yes we run one looping sequence for 24+ hours, so the result list grows over this period of time.

We have a prompt in postUUT that asks "log to database?".  We have this because there are several runs that are nothing but useless data (development, uut setup sequences) which we don't want to clutter the database up with.  So we're in a bit of a catch22. 

I will try adding the /3gb switch in the boot.ini that the article mentions also.

I wonder if there is a 64 bit teststand in the works?

Dave

[dug9000]

If you are running in a loop you should be able to log at the end of each loop and clear out the results to make room for the next loop. Also, if you know in advance that you don't want logging for a run you could just disable result collection in teststand and then you won't use any memory for it and the logging code will then just have nothing to log.

I don't think you are in a catch 22 with using on the fly or periodic logging if you know in advance for a run whether or not you will want to log the results, if so just disable result collection in preUUT rather than prompting after the fact in postuut. There is a global setting for this that can be set programmatically. Also for your setup sequences you can just set the sequence property setting on them to disable result collection specifically for those sequences. There are all sorts of levels at which result collection can be disabled, both at runtime and at edittime.

I wouldn't assume there isn't someway to get the periodic logging to work in a way that still supports the functionality you require. If you give us more details about why it's not working for you currently, perhaps we could help. It seems like it should be possible to log your results periodically rather then all at the end of your 24 hour period which would probably be better from a memory usage, performance (if you are using virtual memory), and less likelihood of losing data perspective anyway.

Hope this helps,
-Doug