64-bit RAM Multi-Process Torture test Starts slowly...

[andres]

I am having an issue on WinXP 64-bit, with the 64-bit version of BIT 6.0.

The first time I run BIT6 RAM Multi-Process Torture test, it runs very slowly, between 1.6B and 1.8B operations in a 5 minute period. If I re-run immediately without exiting BIT6, I generally get between 7.8B and 12 B operations in the same amount of time.

I thought it was related to rebooting and tried doing two BIT6 scripts in a row, one doing a very small amount of RAM along with the other tests I wish to run, then a second test that runs and just does the torture test but this was no better.

I am wondering if there is a solution to this (I would prefer to run BIT6 once) or if there is a way to switch .bitcfgs in the middle of running BIT6 and if there are any issues with that and log files/pre tests?

Thanks,

Andre

[Ian (PassMark)]

Slow system behavior when using the Memory torture test is most likely caused by excessive paging (swapping memory pages to the page file on the Hard disk) casued by over allocation of memory. Assuming you are not trying to explicitly test the paging mechanism, but rather test the RAM, I would suggest reducing the Torture test settings (of 10 processes of 7% total RAM each), or if you are using V6.0 of BurnInTest, consider using the standard test memory test.

[andres]

I must start off by saying that your timeout in message posting is incredibly frustrating as it killed off about 20 minutes of test results that I was writing. The summary is:

I am running BIT6 with 3 minute time length, memory tests at 100% duty cycle, memory is the only thing running. I am doing the torture test with 10 threads at 6% each. When booting up and running the first time, I got 0.7 Billion operations, running again w/o shutting down and without closing and re-opening BIT6, I get about 1.4B, doing it again I get about 2, doing it a 4th time gets me about 5.5 Billion, and beyond that, without quitting BIT6 I get about above 6 Billion operations.

I have seen where closing and reopening BIT 6 seems to reset this back to the slower initial speed with subsequent speedups but I am not seeing this at this moment. A warm/cold reboot does cause it to go back to this slow behavior.

This is a summary of the hardware/software I am running
Intel® Core™2 Duo with 2GHz Intel® GS45 and ICH9M SFF
DDR3 SO-DIMM up to 8 GB, dual channel
Windows XP x64 SP2 Build 3790
64 bit BIT6 Pro build 1019

[Ian (PassMark)]

I will ask our website administrator what can be done about the Forum timeout.

Does the same memory test problem occur if you run the standard memory test at 100%? In V6.0 of BurnInTest, the standard memory test is almost the same as the torture test, the main differences are that the number of memory test processes are fixed and the amount of memory tested is managed such that there is not excessive paging.

Does the same problem occur if you run the memory torture test at with settings of 10 x 4%?

How much RAM does your system have?

[andres]

I just know the standard one runs too slowly. We are looking to test at least 50% of the memory in under 4 or 5 minutes. These systems have 4 to 8GB in them. But why does the exact same test run faster each time you run it? Is there some kind of caching?

Thanks,

Andre

[David (PassMark)]

As far as I know there is no 20min timeout on writing a post. Do you remember the exact error?

There is a timeout on editing an existing post, so you can only update a post for 700min after first creating the post (this is done just to prevent some spamming techniques).

[Ian (PassMark)]

As I mentioned, I would suspect the problem is caused by execessive paging activity due to over allocation of memory. Writing/reading memory pages to the disk paging file can slow memory access down significantly. The behavior could change over multiple test runs due to changes in the system cache size, or any process memory usage.

If you run the Standard memory test at 100% then it will run 4 memory test processes and should not be any slower than the torture test on a system with up to 4 CPUs (cores/hyperthreads). For your reference my office system (4 core CPU) tests about 1GB with 1 test pattern each 20 seconds (about 2 Billion operations per 20 seconds) using the standard RAM test (when no other tests are running).

The memory test is CPU intensive, so if you have other CPU intensive activities, then this can also slow the memory test.


Does the same memory test problem occur if you run the standard memory test at 100%?

Does the same problem occur if you run the memory torture test at with settings of 10 x 4%?

[andres]

Core 2 Duo, P9300, 2.26 GHz, 4GB of memory and here are the results of my testing on XP x64 with the 64-bit version of BIT6 PRO, Billions of operations per 3 minute test:

Test_______________Run1___Run2___Run3__________Run 4_________Run5__________Run6
Standard Cyclic____0.685__1.36___2_____________2.88________ _3.252_________7
1 thread, 40%______0.68___1.33___3.4 (2:45)*___3.4 (1:16)*___3.4 (1:15)*___not run
2 threads, 20% ea._0.68___1.36___4 (2:12)*_____3.6 (0:45)*___3.6 (0:45)*___not run
4 threads, 10% ea._0.69___1.37___4.95 (2:14)*__3.97 (0:46)*__3.95 (0:46)*__not run


Note, I soft rebooted after every test, but not between runs, nothing else was running, either in BIT 6 or separately.

I tried with the same hardware except a different SATA drive with a 32 bit XP installed with BIT6 Pro running build 1002.
Again with Memory running alone at 100% duty cycle, this is what I got:

Test_________________Run1__________Run2
Standard Cyclic______3 B (0:37)*___3.1 (0:37)*
4 threads, 10% ea.___3.5 (0:41)*___3.54 (0:41)*


*(min:sec) when a unit completed a run before the time limit for the test.

Clearly there is a difference between the 64-bit version and the 32-bit version. I know the 32-bit is testing less memory, but the number of operations should not be so vastly different. Also, if it was just the 64-bit OS causing the problem, why does it start geting faster and faster for each subsequent run?

Thanks,

Andre

[Ian (PassMark)]

The memory test can adjust the test memory size at the end of each test cycle. This can result in periods of inactivity while the adjustment is made. When you first run the memory test, this adjustment can occur more frequently (e.g. as Windows cache is released for testing by BurnInTest), the more adjustments made, the lower the average test speed.

You should be able to increase the speed on a 64-bit system, by using 64-bit test patterns. The memory test should also be faster if you use the memory test as a Pre-Test (see Preferences->RAM).

[andres]

I tried just doing a 64-bit test, one pattern and in 3 minutes on the first run, I was only able to do 0.7 B operations.

This is really an issue because it takes so much more time to run 64 bit memory tests than the 32 bit do you know if it has this problem with windows 7?

Thanks,

Andre

[Ian (PassMark)]

Can you please answer my original questions as this should help:

Does the same memory test problem occur if you run the standard memory test at 100%?

Does the same problem occur if you run the memory torture test at with settings of 10 x 4%?

Also, ff you would like to email us a Level 2 trace log (*.trace files) of your test run (setting in Preferences->Logging) then we can see if that helps. Email address shown here::
http://www.passmark.com/support/index.htm

[andres]

Can you please answer my original questions as this should help:

Does the same memory test problem occur if you run the standard memory test at 100%?
Yes.

Does the same problem occur if you run the memory torture test at with settings of 10 x 4%?
Yes.

Also, ff you would like to email us a Level 2 trace log (*.trace files) of your test run (setting in Preferences->Logging) then we can see if that helps. Email address shown here::
http://www.passmark.com/support/index.htm

Will send by the end of today.