FSB Overclocking Results

Front Side Bus Overclocking Testbed
Processor: Core 2 Duo - E6300 1.86MHz
Core 2 Duo - E6700 2.66MHz
CPU Voltage: 1.325v
Memory Settings: 3-4-3-10 at 667MHz
Memory Voltage: 2.1v
SPP Voltage: 1.5V
FSB Voltage: Default
Cooling: Scythe Infinity
Power Supply: PC Power and Cooling 850 SSI
E6300 Overclock: 321fsb x 7 (2247MHz) +21%
E6700 Overclock: 320fsb x 10 (3200MHz) +20%

This board underperforms as an overclocker when comparing it to the Intel chipset boards with our best current in-house P965 boards hitting 7x535FSB and 10x395FSB with the same setup. At these settings the system was able to complete our benchmark test suites three consecutive times along with Dual Prime95 and SuperPI 32M without issue.

We had the LDT set at 3.5X and tried 3X but our board would not even post at 325FSB with either processor. Based upon our previous overclocking results with the C19A boards we are not surprised by the results. The current generation NVIDIA Intel Edition chipsets have never been known for their high FSB overclocking ability and we will have to wait for the next generation chipset to see better results. We will continue working with the board and will provide an update on our results once we have completed additional overclocking tests.

Memory Stress Testing
Memory Tests


This memory stress test looks at the ability of the ASUS P5NSLI to operate at the officially supported memory frequencies of 533MHz DDR2 at the best performing memory timings the TwinMOS Twister DDR2-667 will support. Note this memory is rated at 4-3-3-10 timings for 667MHz operation and was required to match our previous test results. Our Transcend memory we utilized in our previous Core 2 Duo memory performance article would not operate properly on this board at the same settings it was capable of in the VIA or Intel chipset boards we tested. This is not an issue with the Transcend memory but the memory tuning on this board.

ASUS P5NSLI
Stable DDR2-533 Timings - 2 DIMMs
(2/4 slots populated - 1 Dual-Channel Bank)
Clock Speed: 266MHz (1066FSB)
Timing Mode: 533MHz - Default
CAS Latency: 3
RAS to CAS Delay: 3
RAS Precharge: 3
RAS Cycle Time: 9
Command Rate: 2T
Voltage: 2.0V

The ASUS was very stable with two DDR2 modules in Dual-Channel at the settings of 3-3-3-9 at 2.0V. We were able to hold 3-4-3-10 2T at DDR2-667 and 4-4-4-12 2T at DDR2-800 with this memory set at 2.1V. The board would run 1T timings at DDR2-533 with our G.Skill, Corsair, and OCZ PC26400 modules but the differences in performance were minimal. We are still running tests at DDR2-667 with 1T timings where there is a measurable difference. However, there were several inconsistencies with other memory modules on this board. We noticed if we strayed too far away from the SPD settings that the board would lock up, generate memory errors, and corrupted a drive image that we are still investigating.

Even though several of our memory modules would easily do 3-3-3-9 at DDR2-800 on other boards we would notice memory errors at relaxed timings of 4-3-3-10 and could not run the board consistently at DDR2-800 without 4-4-4-12 timings. We feel like the issue is attributed to our 2.1V limit and the initial BIOS release that appears to be geared for conservative timings at this point. We are working closely with ASUS and NVIDIA on this issue currently. Our advice at this time is not to push the memory too far on this board until additional tuning and testing has been completed.

We will now install DIMMs in all four available memory slots, as that results in more strenuous requirements on the memory subsystem than testing two DDR2 modules on a motherboard.

ASUS P5NSLI
Stable DDR2-533 Timings - 4 DIMMs
(4/4 slots populated - 2 Dual-Channel Banks)
Clock Speed: 266MHz (1066FSB)
Timing Mode: 533MHz - Default
CAS Latency: 3
RAS to CAS Delay: 4
RAS Precharge: 4
RAS Cycle Time: 12
Command Rate: 2T
Voltage: 2.1V

The ASUS was completely stable with four DDR2 modules in Dual-Channel operation at the settings of 3-4-4-12. We tried several combinations of memory settings and memory modules at lower timings but the board was not stable enough to complete our test suite. Overall, the memory tuning on this board needs some additional work. Once you dial the memory in then the board is extremely stable, but we know the chipset is capable of a little more performance. We will continue our memory testing with other modules that have arrived recently and hopefully we can get a BIOS update shortly.

ASUS P5NSLI: Features Test Setup
Comments Locked

27 Comments

View All Comments

  • Gary Key - Tuesday, August 22, 2006 - link

    quote:

    Funny how your original look at NForce5 (as linked on page 2 of this article) showed 570 was supposed to also include DualNet, yet this board does not. :[


    That is due to the fact they are using a different chipset than the AM2 family although the marketing language is the same.
  • scott967 - Tuesday, August 22, 2006 - link

    I'm trying to understand the chart on memory which compares different chipsets. The Via PT580 falls apart on Sandra standard going from 533 to 667 memory. Is this correct?

    scott s.
    .
  • Gary Key - Tuesday, August 22, 2006 - link

    quote:

    I'm trying to understand the chart on memory which compares different chipsets. The Via PT580 falls apart on Sandra standard going from 533 to 667 memory. Is this correct?


    That is correct. ASRock and VIA have figured out the issue, just waiting on a fix that hopefully is bios related and nothing else.
  • Spacecomber - Tuesday, August 22, 2006 - link

    This came up before with another article, but perhaps it needs to be said again, I wish that Anandtech would stop using charts showing comparitive FPS that don't show a full FPS axis that starts with zero.

    I understand that you are trying to highlight the small differences that are being measured and that if you have a chart that uses a proper axis, starting at zero, these differenes are harder to see. However a chart with an axis starting with zero is still a better representation of the results than using a distorted graph to draw out the differences.

    Essentially, all you have graphed are the differences between the different results, and if this is what you want to do that is fine. Just relabel the graph and change the axis to show this. Call it something like "Increase in FPS with Memory Speeds Faster than DDR2-663" and then have an axis that runs from 0 to 5 FPS, since that should about cover all your results.

    Obviously, such a graph would not be very appealing or interesting, but it would be in better keeping with your data. And, the fact that it doesn't seem to be a very informative graph is precisely my point. Trying to dress these charts up, which really are only charts of the small differences between your results, as if they also provide a relative comparison of the different FPS with different motherboards and different memory timings, simply confounds things. You would do better to pick one or the other to represent, but not mash both together as you are doing now.

    It is bad enough that these statistics are posted in such a manner that pays little heed to the kinds of variations that are involved. Magnifying tiny differences in order to make them seen more significant only compounds the problem. Without these distorted graphs a reader might more correctly conclude that the differences in the frame rates, comparing these two different motherboards while using memory running at different speeds, are essentially insignificant. And, drawing out speculative conclusions, based on the perception of any differences, is most likely just much ado about nothing.
  • hibachirat - Wednesday, August 23, 2006 - link

    I don't mind those. But the red and green lines are to close for my red-green color blindness. I can almost tell them apart...but would be nice it the green was brightened and/or the red darkened just a bit.
  • Gary Key - Tuesday, August 22, 2006 - link

    quote:

    This came up before with another article, but perhaps it needs to be said again, I wish that Anandtech would stop using charts showing comparitive FPS that don't show a full FPS axis that starts with zero.
    Zero based graphs are available by clicking on the orginal image. :)
  • Gary Key - Tuesday, August 22, 2006 - link

    quote:

    This came up before with another article, but perhaps it needs to be said again, I wish that Anandtech would stop using charts showing comparitive FPS that don't show a full FPS axis that starts with zero.


    Our full review will not utilize these charts. Instead of separating the information and showing pages and pages of the data we felt like this was the best way to collectively show it all at once. We end up with either a graph that has the majority of data points stacked into a single line path or the other evil of not having a zero based graph. We are still working on an updated engine so hopefully this issue disappears quickly or we go back to the bar charts.

    Personally, it really bothers me not to have a zero base graph. I will work on another alternative today and update the article if it works. Thanks for the comments and we do agree with you.
  • JarredWalton - Tuesday, August 22, 2006 - link

    We have added a zero-based graphs as pop-ups if you want to see those results. The number tables at the bottom of the charts are intended to help you see that the scores really aren't that far apart, but now you can see the true relative difference.
  • shecknoscopy - Tuesday, August 22, 2006 - link

    Well, I've never been that discouraged with their axis labeling, but I could see how someone unfamiliar with the world of statistics could be misled by purported performance differences that are actually within the measurement error.

    Personally, if I were the one reporting these data, I'd use <b>both</b> methods. Plot the data as you currently do - so as to highlight subtle differences, and <b>also</b> place them on a full graph (where y ranges between 0 and the maximum observed value) in an inset. That way you get a nice zoom-in on the "interesting stuff," and a smaller zoom-out to illustrate that the differences are typically minor, compared to the absolute values.

    I'll also point out that, if you <i>really</i> want to get persnippity about their stats reporting, you should demand that they repeat their tests several times, and report each datum with an error bar. :)

    Of course, most of my suggestions for improvement involve the word "bar."

    -sheq
  • Renoir - Tuesday, August 22, 2006 - link

    I feel it's important to put a lot of these results in perspective with regards to their level of significance. For me personally when looking at results I find the thing that I find most useful is percentages. Lately it seems that a lot of system variables (memory timings/frequency, cpu cache etc) often result in differences of less than 10% in most cases which to me isn't that significant when just getting 1 higher speed bin on your cpu would get you that and probably for less money than say buying the very best ram. I guess I'm saying that when I see graphs that are zoomed in to highlight minor differences I find myself thinking "ok I see why they've done that but it would be nice to be given a percentage so that I can make a quick and dirty evaluation of whether the difference is significant or not". Just some random thoughts :-)

Log in

Don't have an account? Sign up now