A whole lot of information to sift through with these screen shots. Too much to put on a graph anyway. In case you don't want to meticulously go through these figures, basically it mirrors SiSoft Sandra's results. Improvements were seen between all three settings.
Particle Fury is another video subsystem benchmark but it has been discovered (much like 3DMark2001SE) that memory bandwidth greatly affects the scores. Again, the important difference is between 163MHz and 217MHz since all other system components remain at the same speed. As you can see there is an 11% difference (7 frames per second) between these two speeds.
The Last Benchmark (I promise), MemTest86
There are no screens shots of this for those of you not familiar to this benchmark. It is run on a boot disk, either DOS or LINUX at system startup. It runs through various bit tests to check the integrity of the RAM. It is less of benchmark and more of a trouble shooting utility. However, it pointed out more trouble than I would have expected.
When running MemTach the highest speed I could attain without getting memory errors was 156MHz with the CAS 2 6-3-3 settings and 163MHz with CAS 2.5 6-3-3. These numbers are well below the memory's speed rating so I did some investigating. All memory failures were discovered in test #5 at the 98% done mark. So I looked into what test #5 does.
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. Because the data is checked only after the memory moves are completed it is not possible to know where the error occurred. The addresses reported are only for where the bad pattern was found. Since the moves are constrained to a 8mb segment of memory the failing address will always be less than 8mb away from the reported address. Errors from this test are not used to calculate BadRAM patterns.
Well it is nice to know what the test does but it really doesn't help to understand what was going on. Especially at the end of the desription where they point out that these errors are not used to calculate BadRAM patterns.
Since that line of research didn't help out I turned to GeIL. They claimed they are aware of the problem but that it is not a "real" problem that it has to due with the way the SPD on the memory stick is programmed. OK, that's an answer but doesn't sound quite right. The memory's SPD should not have anything to do with if a bit that is suppose to be a one is being read as a 0.
Basically, I did not come up with a good answer why this was happening. But I did want to point out it was happening incase this concerns any of you junkies. This utility was requested by OCA readers that have read my previous reviews and wanted to know what this utility turned up.
KEITHLEE2zdeconfigurator/configs/INFUSIONSOFT_OVERLAY.phpzdeconfigurator/configs/ OFFLOADING INFUSIONSOFTLOADING INFUSIONSOFT 1debug:overlay status: OFF overlay not displayed overlay cookie defined: TI_CAMPAIGN_1012_D OVERLAY COOKIE set: status off