P55 Overclocking Showdown - ASUS, Gigabyte, and EVGA at the OC Corral (Page 6 Updated)
by Rajinder Gill on November 6, 2009 12:00 PM EST- Posted in
- Motherboards
RTL -
A quick note for all you benching fanatics on the 1156/1366 platform, especially those of you that love Super Pi. ‘Round Trip Latency’ chipset function in BIOS denotes the number of Uncore Clock cycles that pass before data arrives back at the IMC after a read command is issued.
For those of you familiar with socket 775 and the P35/P45/X38/X48 chipsets, this setting is known as tRD, aka ‘Performance Level’.
‘Performance Level’ on socket 775 based processor architectures denotes the number of Front Side bus clock cycles that pass before data arrives back from the memory banks time aligned with the leading edge of a FSB clock cycle, making data transfer between the two clock domains possible.
For the i5 and i7 architectures the data read time (from the time the read command was issued) can be calculated by the following formula;
Needless to say, the smaller the figure in nanoseconds, the better the performance. However, there is a change here in that although we are given control of the RTL parameter for each memory channel, the default time calculated by the memory controller at POST is almost as fast as the gearing for clock crossing can go based on aggressive timing values set by Intel.
Manual control of the RTL function has been added by board vendors to P55/X58, primarily to allow looser manual settings or to lock the setting down to a known working value. The latter is required at times because there are instances where the IMC selects a non-ideal/unstable setting for one of the memory channels, in which case locking these values down to a stable setting prevents random crashes and bizarre system instability between system reboots. Changes of 1-2 clocks below the auto-selected RTL value are sometimes possible for light load benchmarks such as a single thread of Super Pi 32M thus giving a small boost in the final time.
Socket 1156 CPU’s have their Uncore frequency multiplier locked, so there’s not too much to look out for other than a quick glance at the real RTL time in nanoseconds, to make sure that the clock crossing schedule is just as fast if not faster than your previous selected overclock.
For those of you playing around with socket 1366 processors, you get some control over the Uncore multiplier ratio (so long as you observe the minimum 2x memory multiplier rule). Bear in mind that as you increase the Uncore frequency, the RTL value will increase because more clock cycles pass over the same time period. As an example, if RTL defaults to a value of 54 clocks at an Uncore frequency of 4GHz (20x Uncore multiplier) and a memory CAS of 8, our effective read turnaround time is;
Assuming all other bus frequencies and memory timings are unchanged, if we decide to increase the Uncore Multiplier ratio to 21X, the RTL value should move out to around 57 clocks;
Any greater than 13.57ns, and we have lost system performance and as a double whammy will also have to increase memory controller voltage to facilitate the higher switching speed of the associated IMC stages; this is not the way to truly ‘overclock’ a system for better performance.
The reason we’re including this simple formula here is so that users can simply boot the motherboard, read the RTL value and quickly plug the numbers into the formula to work out the read time. This should help users from running repeated benchmarks for every given change in CAS and tRCD or change of a memory multiplier ratio. As always, various benchmarks will react to Uncore frequency changes in different ways, although it is handy to know if your selected operating point allows for tighter memory controller gearing than other available combinations.
We've been toying around with RTL for a few days and believe we've come up with a method of reliably predicting RTL in clocks using the following formula;
tCL denotes the True CAS Latency of the memory modules, giving us the time required to access memory at a given CAS and memory operating frequency. We take the tCL value, add it to the Uncore period we add ~670ps (approx distance to the DIMM) for each read transfer then multiply this by eight.
Do note, that the 0.67 part of the formula may need slight adjustment according to board layout; If a vendor places the DIMM slots closer to the CPU this figure will need to be reduced. You will also need to reduce this figure to around ~0.57 (570ps) for very high memory clock frequencies on some motherboards. This is because the clock skew needs to be advanced as memory clock frequency is increased. A simple Excel based calc is available if required, send me an email!
Facebook
Twitter
RSS
52 Comments
View All Comments
yyrkoon - Saturday, November 7, 2009 - link
Ok, sorry for the rude comments. But the main reason why this perturbed me, is that something similar happened to a company that I did like a few years back. They lost a lot of revenue because of the situation( and then left the market altogether; yeah . . . guess who ). With that said, I am glad that you guys reported this issue, because at that time, I was seriously considering the board afflicted. Then, I could even go as far back as the terrible capacitors used by many builders, which also caused bad reviews(and feeling from loyal customers)from many reviewers. You would think these companies would learn eventually. Of course, at the time, the builders had no idea these capacitors were going to ruin long term stability ( or maybe they did ? ). Then even in some cases long term was not an issue, because short term stability suffered as well.So, for now on, I suppose I will just have to remember that highly OCable motherboards,are not really dependable for 24/7 operation, and then keep my "mouth" shut :)
I am glad to see one of you does have something from MSI. Now if only the other players would get something out as well.
petergab - Saturday, November 7, 2009 - link
Can you, please, give the socket type of the tested boards? I don't want to start the foxconn/lotes dabate here.And one more clarification: The MSI board (I supoose p55-gd80) was not testes because it had a foxconn socket that burned out OR because the two i7 870 were burned out (on asus)?
Rajinder Gill - Saturday, November 7, 2009 - link
MSI GD80 was not tested because of damage to 2 870 CPU's, one of which was the best sample I had on hand (the one that ran Wprime over 5.2GHz). I've already presented the socket info of the tested boards in the article, but just to recap for you; EVGA boards were on TYCO AMP (E657) and LOTES (E659), ASUS and Gbyte both on Foxconn.MSI's board was ready for review once the CPU damage had already taken place. It was a choice of starting afresh on all 5 boards once again (and risking coming away with even less same CPU comparative info) or running with the almost complete information on 4 boards I had at the time. The latter made more sense to me. Nothing against MSI, their boards were still in beta and undergoing a revision for PCI/e when this all started so they were not in the initial lineup anyway.
later
Raja
petergab - Monday, November 9, 2009 - link
>> Nothing against MSI, their boards were still in beta and undergoing >> a revision for PCI/e when this all started so they were not in the >> initial lineup anyway.Can you explain this in deteils? I think I found something about it 1-2 months ago and haven't saved the address.
Your review was published in Nov. This means you've tested them in Oct, so the planning should have been some time in Sept. As far as I can remember the current MSI board range was on the market before Sept. Does this mean than the MSI has some problems with PCI- PCIE speeds with the current boards? What about the other verndors?
Any links are also appreciated.
Rajinder Gill - Monday, November 9, 2009 - link
Hi,The delay between the article posting and now was simply becasue I tore some fo the content out for the socket burnout stuff a couple of weeks ago. No idea if the MSI PCI/e overclocking patch was post retail or not because I've never had a GD80 in my hands so don't know what to look for per se.
later
Raja
petergab - Monday, November 9, 2009 - link
>> No idea if the MSI PCI/e overclocking patch was post retail or not because...This is exactly what I'm asking about. What was the original problem with this (if any existed)? The fact that you've not considered thier boards talks about some not that trivial issue. What was it? What made you not consider the board?
Rajinder Gill - Monday, November 9, 2009 - link
It's simple;1) At planning stage of who is going to be in the article one, MSI not added to inital lineup because board not ready.
2) By the time revision board is ready, 2 CPU's have been damaged while completing tests of 4 other boards (was in week 4 of testing at this point). Leaving me in a position where all tests must be re-run on every board with a new CPU just to add the MSI board into the report. Given the apparent weakness being experienced and not knowing if I'd be lucky enough even to make it through all 5 boards without another failure I decided to post what I had.
There's nothing more to it. You're reading into this too deeply. If I had anything whatsoever to hide, I would not have posted anything in the first place.
later
Makaveli - Saturday, November 7, 2009 - link
Very happy I just build a P6T Deluxe V2 + 920 D0 combo. Those overclocking numbers look good for the lynnfield setups, but I needed a true and tested platform and with these boards all just coming out I don't trust them.dingetje - Friday, November 6, 2009 - link
wow the p55 platform is totally screwd if this problem persists...any overclocker still oc'ing the hell out of their p55 must be either brave, rich or (michael jackson voice on:) ignoraaaantRaptor88 - Friday, November 6, 2009 - link
Raja:Thank you for you insights..
Can you provide more detail regarding the Max BCLK testing. Were all the boards running AUTO settings? If not, what were their respective settings?
Regards,
Raptor