I thought I would share my experience with MemTest 86 memory test and how my CUSL2 board performed. The MemTest 86 is downloadable from MemTest 86.
I was running these tests on the CUSL2, updated to the 1003 BIOS. The processor is a PIII700 running at 933 (1.65v). I was using MemoryMan Mosel Vitalic memory: 2 sticks of 128mb memory and 1 stick of 256mb memory. These are all double sided modules.
Basically, I discovered that one of the subtests of MemTest 86 uncovered memory errors in many situations. Test 5 was the one picking up on these problems. The readme describes this test as follows.
<< Test 5 [Block move, 64 moves, cached]
This test stresses memory by using block move (movsl) instructions and is based on Robert Redelmeier's burnBX test. Memory is initialized with shifting patterns that are inverted every 8 bytes. Then 4mb blocks of memory are moved around using the movsl instruction. After the moves are completed the data patterns are checked. >>
To summarize what I found, with the 133mhz memory bus I could run a single stick of memory (any of the three would work) without producing errors on Test 5, but only if I used the first or third DIMM slot. I could run the memory modules at the full 22257 settings with these conditions. If I tried more than one stick of memory, I would get errors (though turning the timing down to 33379 and using the first and third slot for two sticks of memory produced less errors).
These problems were only present at the 133mhz busspeed. If I set things to 100/100/33, there were no problems with any of the slots, even using all three sticks of memory for 512mb total.
However, trying the 133/100/33 setting did not seem to help. This is a bit surprising from a logical perspective, but it is consistent with my prior experience that the asynchronous setting is problematic on this board. I don't think this means that the memory test failure is related to my overclocked PIII, since I do not get errors at 133/133/33, if I only use one stick of memory in DIMM slots 1 and 3.
I also tried some other tweaks, including the "strong" BIOS setting for the memory, but this only seemed to increase the errors, and I tried the different VIO voltages (3.3, 3.4, 3.6), but these didn't seem to make any difference either.
I think this test is showing some basic problem with the memory controller on the CUSL2. At least, it seems to be showing this problem on my board. I'd appreciate hearing from anyone else who might wish to experiment with MemTest 86 on their CUSL2.
I think this test (especially test 5) is a good one for overclockers to test out the stability with their systems. It appears to stress the CPU, the cache, the memory controller, and the memory functioning itself. As the readme quotation mentions, it borrows from a stress test called burnBX, which can be found here .
I think the problem being picked up on with the CUSL2 is a subtle one. My system seemed to be running well enough, even with all 3 sticks of RAM installed and the 22257 timings. It passed the usual stress tests of Prime95, ran 3D graphics benchmarks, and my Sandra memory scores stayed the same as installed more memory. I could play a resource intensive game, Battlezone2, for hours. My own hunch is that most of these tests only use memory from one module, and if they do use more than one module's memory, they aren't moving data from one module to another.
Again, I would appreciate feedback from anyone else with their experience using MemTest 86, especially on the CUSL2, or annecdotal experience with the CUSL2 and it's memory quirks.
TIA,
Spacecomber
I was running these tests on the CUSL2, updated to the 1003 BIOS. The processor is a PIII700 running at 933 (1.65v). I was using MemoryMan Mosel Vitalic memory: 2 sticks of 128mb memory and 1 stick of 256mb memory. These are all double sided modules.
Basically, I discovered that one of the subtests of MemTest 86 uncovered memory errors in many situations. Test 5 was the one picking up on these problems. The readme describes this test as follows.
<< Test 5 [Block move, 64 moves, cached]
This test stresses memory by using block move (movsl) instructions and is based on Robert Redelmeier's burnBX test. Memory is initialized with shifting patterns that are inverted every 8 bytes. Then 4mb blocks of memory are moved around using the movsl instruction. After the moves are completed the data patterns are checked. >>
To summarize what I found, with the 133mhz memory bus I could run a single stick of memory (any of the three would work) without producing errors on Test 5, but only if I used the first or third DIMM slot. I could run the memory modules at the full 22257 settings with these conditions. If I tried more than one stick of memory, I would get errors (though turning the timing down to 33379 and using the first and third slot for two sticks of memory produced less errors).
These problems were only present at the 133mhz busspeed. If I set things to 100/100/33, there were no problems with any of the slots, even using all three sticks of memory for 512mb total.
However, trying the 133/100/33 setting did not seem to help. This is a bit surprising from a logical perspective, but it is consistent with my prior experience that the asynchronous setting is problematic on this board. I don't think this means that the memory test failure is related to my overclocked PIII, since I do not get errors at 133/133/33, if I only use one stick of memory in DIMM slots 1 and 3.
I also tried some other tweaks, including the "strong" BIOS setting for the memory, but this only seemed to increase the errors, and I tried the different VIO voltages (3.3, 3.4, 3.6), but these didn't seem to make any difference either.
I think this test is showing some basic problem with the memory controller on the CUSL2. At least, it seems to be showing this problem on my board. I'd appreciate hearing from anyone else who might wish to experiment with MemTest 86 on their CUSL2.
I think this test (especially test 5) is a good one for overclockers to test out the stability with their systems. It appears to stress the CPU, the cache, the memory controller, and the memory functioning itself. As the readme quotation mentions, it borrows from a stress test called burnBX, which can be found here .
I think the problem being picked up on with the CUSL2 is a subtle one. My system seemed to be running well enough, even with all 3 sticks of RAM installed and the 22257 timings. It passed the usual stress tests of Prime95, ran 3D graphics benchmarks, and my Sandra memory scores stayed the same as installed more memory. I could play a resource intensive game, Battlezone2, for hours. My own hunch is that most of these tests only use memory from one module, and if they do use more than one module's memory, they aren't moving data from one module to another.
Again, I would appreciate feedback from anyone else with their experience using MemTest 86, especially on the CUSL2, or annecdotal experience with the CUSL2 and it's memory quirks.
TIA,
Spacecomber
Facebook
Twitter