Originally Posted by Jpmboy
oh well, I'm waaay off the Reservation at this point, no sense in turning back... guess I have an on-going robustness test of sorts
The song Suicide Blonde comes to mind. 64GB
Thank you very much for taking a look! Yes these settings have been used for a little over a week and stressed in all sorts of manners including gsat. No errors from that or memtest86+.
1) I have heard mixed stories about tREFI. On one stance if you have no issues with stability you should max it out. One the other I have heard the maximus hero viii actually sets these values very well and should always be left on auto. Taking what you said into account I think I will move that value back to auto and see what I can do as far as further adjusting terciary timings.
2) If I am not having an issue using the current timings should this value still be adjusted?
3) When I was asking questions on the ram addict club forum the guys there told me that I should always set to a value of 9 despite CAS. Them knowing much more than me I listened haha. Is this a problem ? I only asked bc it was more than ones opinion in the thread to adjust this to 9 despite CAS
4) I know the value of 16 is well below 4*(tRRD)=24. Im guessing 24 is being applied there.. Triyingto reduce tRRD further resulted in code 3E.
1) Try 2x what the board sets on auto.. so far this has been fine with a continuous ram disk (and days of up time) and overnight sleep (suspend to ram) cycles. But there's always an inherent risk.
2) does setting it that low actually improve the performance? If yes, then stand pat.
3) remember, the guys in the ram addict club are fairly extreme in their uses and voltages (which is fine). I'm running 9 with cas 13 also, but got there differently.
4) No idea what value the bios/board/mc is applying to the timing error. By setting it to 4x tRRD you know what value is being used. If you can lower it from there and gain performance and stability/reliability - the board may be running an offset as Praz and Raja have suggested.
These two guys know this sheet like you (we) know your day job... I tend to listen to them, and then wander off the margins at my own risk.
Originally Posted by Blameless
Lower tRFC will scale up performance, with diminishing returns, as far as you care to take it because less time is spent refreshing. However, stability will get flaky very rapidly as you near the minimum values a particular set of ICs can tolerate at a given clock speed. The difference between completely stable (or as close as one can get) and having to reinstall your OS can be razor thin.
tREFI works similarly to tRFC (former is time between refreshes, later is how long a refresh lasts), though higher is better and gains tend to be more linear. The line between stable and unstable is usually much more subtle though as well as more temperature dependent.
With regard to tWCL, you can test and see if the value is actually sticking pretty easy with memory write benchmarks. If it's offering benefit, then there is no reason not to use it, as long as you can be convinced of stability.
Hey guys thank you very much for the detailed explanation! I spent some time testing and this is what I found. Note setting were proven stable so the rest is under the assumption all testing was completed at stable operating conditions.
1) changing tREFI to auto then changing it to 2*Auto and finally adjusting it to MAX value shows zero changes in perceived stability and AIDA throughput. I also tested with superPI and 32M receives same time. With that should I just leave the values set to auto or is there something about the longer refresh that will help other things not being seen by this particular test method?
2,3 & 4) Changing both values higher (tRFC to 320, auto then back to 250), ( tFAW from 16 to 24)and( tWCL from 9 to 13) all show very slight but quantifiable improvements in throughput on AIDA with a four run average. So I guess it seems to actually be applying the values so im assuming I should leave these alone since there are no issues?
Again thank you for the help it goes a long way in understanding the relationship between all the timings. maybe @Raja@ASUS
can chime in and fill me/us in on what is really going on here.