The article in question is:
ASUS ROG Rampage Formula: Why we were wrong about the Intel X48
Tony over at the OCZ support forum posted a tRD calculator using the same formula, so I asked about it:
Re: tRD(performance Level) Calculator ver1 DD2 ONLY Intel Chipsets
(Credit means different things to different people. A performer can seem obsessed with getting their name around, but they're worried about being able to eat. An academic truly just wants to know what to read next. Missing credit to us is like a hanging pointer to a C programmer.)
So the story is that Kris Boughton and Tony started
the tech repository before Kris came to AnandTech. Kris found this formula through Intel sources he doesn't wish to divulge (I struck out trying to google for this), so at a minimum the formula applies across a chipset, though each board maker gets to fiddle with BIOS as they please. In any case, the formula is close but not exactly correct for me, and it only predicts posting, not stability.
As I say there, the equals sign is in the wrong place for reasoning intuitively about the formula. The thing to do is to convert both tRD and memory timings into nanoseconds.
Edit: What follows is independent of the chipset; I'm ignoring the X48-specific constants in the
article. I have a P35 chipset.
In my spreadsheets tracking overclocking experiments, I'll have columns
A: FSB (e.g. 356)
B: DDR (e.g. 1068)
C: tRD (e.g. 5)
D: CAS (e.g. 5)
DDR is computed from
FSB and the memory multiplier, but how one says this varies by BIOS.
Now, to compute (for row 2)
Trd, the time in nanoseconds that the MCH waits around, derived from the FSB clock, I use
=1000*$C2/$A2 (e.g. 14.04)
To compute (for row 2)
Tmem, the time in nanoseconds that
CAS takes for the memory sticks, derived from the DDR clock, I use
=2000*$D2/$B2 (e.g. 9.36)
Now,
Trd needs to be a longer duration than
Tmem, so the MCH has time to finish its part of the work and pass it on. The formula Kris gives quantifies this for some boards. I find it more useful just to look at the two durations, and decide on hunch and experience if that particular overclock has a ghost of a chance of working. The sample numbers have plenty of room, yet one click down doesn't work for me.
A lot of pronouncements get made in this business, of the form
"higher FSB is better" and so forth, that would make sense if our choice space was a giant blob, and we were trying to move to the sunny end of the blob. In fact, our choice space for a given cpu speed is a finite set of points, and the best point may not be near the end of the blob that received wisdom asks us to use, for entirely quirky reasons depending on our exact configuration. Changing the FSB by one click can entirely change this picture, rearranging the stable point cloud. This is a famous mental image for engineers, it's the difference between linear programming and integer programming.
In practice, what this means to me is that for a given overclock, I want to make a spreadsheet listing all my options, sort the rows by estimated performance, rule out rows as impractical e.g. too tight a
tRD or too high an
FSB, then start stability and performance trials to see what works.
I've been regressing various computations that are realistic for what I want to do. Some exhibit excellent cache behavour, and memory settings basically don't matter. Others thrash the cache, and memory is still minor compared to cpu speed. In these cases,
tRD and
CAS are about equally important for me, so, yes,
tRD is definitely worth tuning.
Hope this helps. I'm ok if it provokes any spirited rebuttals. Another cultural variation, like the credit thing: Mathematicians call each other idiots all the time (or so it appears from the outside) when all they did was mess up a sign. We're used to being corrected. I've noticed that people outside this tradition can be rather sensitive on forums to "competing evidence", even though our tradition here is primarily to set the record straight for all the lurkers who might actually believe us.
