The only thing is that on 1.47 FSBT you ran OCCT on Large setting, while in the second you ran on small. On small, it will stress the CPU, and quiet not the NB-RAM. The calculation data is so small it fits the CPU cache, so no need to go in RAM --> NB and RAM not tested much. Maybe that's why you got no cripple in second test.
The RAM mode is the mode that will stress the much RAM and NB. remember, that the main difference between modes is the data size. Small data remains in CPU cache, big data is transferred to RAM through the NB
Would be interesting for you to vheck also your NB temperature when you crash, also the VDIMM voltage noted to fall by others. The RAM on this boards has two PWM that can also get too hot --> ram voltage drop
Just some ideas to explore...
Also
Speedfan logs can be of a huge help too. Whatever kind of crash, even OS reboot, the log file is written to HD in real time and saved. So, on reboot or recovering of a blue screen, you open the previous log (as speedfan creates a new log file on each start) and you can see the values of your logged settings at the crash second. It helped me identifying a vcore delayed drop after 2h of stress testing: my PWM were getting hot and delivered a lower voltage to CPU
Silly question maybe, but, you're setting your RAID while overclocking? If yes, than try at stock. If not, ignore my comment
It's a very good idea to make a first full check and tests at that 3.6GHz point. So, if it is rock stable, unbreakable, you can go ahead basing your settings on the 3.6GHz reference point. But, hope you can get higher later. It'll be disappointing to see the Maximus topping at 3.6GHz as a rock solid setup, and to see that anything above that is not stable on all benching programs
Windows check disk, and tick: check bad sectors. Long test, but tests read/write operations of all clusters








Reply With Quote
Bookmarks