Overclocking (Main Thread)

Are you actually sure that's a desktop Barton?
Their multiplier maxes out at 12.5—anything higher requires a mod.
It can't go past 12.5x because the bridge is cut... it's not even connected, really! How are you pulling that off? Does anyone else have one of these Barton chips?

Everything looks fine in my signature, but since they disabled the img code here, it just shows up like this: http://www.2crowded.com/Blade/Signature%20copy2.jpg

I don't get it... is the memory actually bottlenecking the FSB? And what even is 333DDR?

Raymond Rodriguez40 said:I don't get it... is the RAM bottlenecking the FSB? And what even is 333DDR?

If you're asking about my setup, here's the deal.

You probably wouldn't even know what I'm talking about.

Basically, I've got this Samsung 400, but it's a total nightmare with compatibility—specifically with Abit nForce boards. On some, it hits 215 FSB, but on others, it won't even budge past 185-190 MHz.

Right now, I'm running it at 173. Even if I hit 15x to get exactly 2600, those extra few MHz of FSB aren't going to save me.

BTW, if anyone has a Samsung module or anything similar—mostly looking for a 512 DDR 400 stick—and wants to swap, let me know.

I've got these Samsung 256MB modules on my Soltek FRN2-RL, but I can't get them to stick in DC—and SPD is just as useless. It runs, but then everything just crashes. Maybe it's a BIOS issue? One works fine, while the other is a total disaster.
But hey, I can push it to 242 MHz on SD. It actually stays completely stable at 222 (or 225) using 9-4-4-3 timings... which puts us around 3300/1150.
It's solid enough, though if I tried this on another rig, it would be a dream—if the price wasn't such a killer. 🙄

Pentium 4 2.8 GHz pushed to 3.6 GHz at 1.6V
Corsair DDR400 memory clocked at 514 MHz with timings 3-4-8-4
Temperatures stay under 45°C under full load, dropping to about 40°C during the winter months

Aggressive latencies are essentially useless anyway; it is much better to increase the memory frequency than to struggle for marginal gains through tighter timings

Sam Evans3, why don't you go ahead and download Prime95 (you know, the torture test)
? Then let me know what kind of temperatures you're seeing on your rig and whether or not the system actually holds up under pressure.

Sam Evans3 said:Aggressive latencies are a waste of time. You're better off bumping up the memory frequency than squeezing out tiny gains with tight timings.

I can't agree with that statement.
Honestly, neither I nor anyone who actually understands how memory works would back that up.

Do a little homework before you chime in next time.

Kenneth White17 said:I can't say I agree with that.
Neither can anyone else who actually understands how memory works.

Maybe do a little homework before chiming in...

I'm right there with you.
When I was overclocking, my own testing proved that dropping DDR 400 down to 333MHz while tightening the latencies actually performed better than pushing the frequency higher with looser timings.

What kind of testing are you even doing?

What’s the max at 333MHz versus what you get at 500MHz!?
Don't just claim that running with 0-0-0-0 latencies at 333MHz somehow beats 3-4-4-10 at 500MHz.

That's just not how it works—on an Intel system, even in dual Channel at 333MHz, you're looking at a pathetic 2700 Mb/s at best regardless of your latencies. If you drop to 200 MHz (maxing out at 3200 throughput), the bandwidth is still higher even with the worst possible settings...
What kind of measurements are you pulling out of thin air? Mathematically speaking, if it's running at a higher clock, it's faster.

Raymond Rodriguez40 said:What kind of testing method did you actually use?

What’s the maximum we can hit at 333MHz versus 500MHz?
Don't just go around claiming that running at 333 MHz with 0-0-0-0 latencies is going to outperform 3-4-4-10 at 500 MHz. Realistically, you can't just make those kinds of claims without looking at the actual math.

That’s just not true. Even if you run the AMD setup in dual Channel at 333 MHz, you're looking at a measly 2700 MB/s under perfect conditions, regardless of what the latencies are doing. If you drop down to 200 MHz, even with the worst possible settings, the bandwidth actually ends up being higher than that, even in single Channel mode.
What kind of measurements are you even talking about? Mathematically speaking, if it's running at a higher clock speed, it’s obviously faster.

Here’s what Kovi from PCEkspert had to say:

CAS, RAS, RAS-to-CAS, Row precharge delay... whether you're shopping for new RAM or trying to squeeze more performance out of what you already have, you’re going to run into these terms. Just a heads-up: some motherboards simply don't allow you to tweak these settings manually in the BIOS. If that's your situation, I'm sorry, but you might just need to upgrade to a newer system—those older machines are basically relics at this point.

When you look at how data actually moves through a system, there are three heavy hitters involved: the CPU, the chipset (specifically the NorthBridge), and your system RAM. Most of the time, your total throughput is going to be bottlenecked by your memory bandwidth. So, if you’re under the impression that the processor is the only thing that matters, you're dead wrong. It doesn't matter if you have a 3200+ speed rating; it won't feel any faster than a 1700+ if you're starving the system of memory. I mean, common sense tells us you can't run Windows XP on a machine with only 64 MB of RAM—well, maybe you technically could, but it would be an absolute nightmare of stuttering and lag. And since nobody is making 64 MB DDR sticks anymore, let's say you try it with 128 MB DDR instead. Sure, Windows XP might boot up, but the performance is going to be painfully slow regardless of how beefy your processor is.

Nowadays, we have Dual Channel memory (Double Data Rate, or DDR), but you can't just plug it in and expect magic—you need a motherboard that actually supports that mode. It all comes down to which slots you decide to pop those sticks into, so definitely check your motherboard manual first. I won't bore you with all the technical minutiae here, but just make sure you follow the layout instructions.

Memory can run in either synchronous or asynchronous mode. But what’s actually the difference? Basically, synchronous mode is when the ratio between the system bus (FSB) and the memory clock is...
Keep your memory frequencies at a 1:1 ratio. If you're running an nForce2 motherboard, that’s definitely the sweet spot. Whatever you do, don't try to switch to asynchronous mode—you'll end up incredibly disappointed with the performance drop. I highly recommend digging into an "All About Overclocking" guide to figure out your maximum FSB; it’s a lifesaver unless you've already mastered the art. From there, our goal is to find that perfect balance between FSB and timings. Just keep in mind that the highest possible FSB isn't always the winner; in my experience, hitting the absolute limit actually hurts performance.

My max FSB hits 235 MHz, but honestly, my performance actually drops off compared to running at 225 MHz. You’re probably wondering why—it all comes down to the timings. Some people will swear that the FSB speed is the only thing that matters, but I don't see it that way. Sure, there might be specific scenarios where that's true, but it's definitely not a universal rule. In reality, you're always looking for that sweet spot.

I'm not sure if everyone here is familiar with this, but there's actually such a thing as chipset latency. Most of the time you'll see it set to 1T, though sometimes it's 2T. It’s a bit of a technical rabbit hole, so some of the stuff I’m about to dive into later might sound like gibberish to some of you.

Let's just assume everyone is running 1T. Honestly, that doesn't even matter much when you're struggling to dial in the tRAS—which is usually the biggest headache anyway. But then again, if you're one of those hardcore overclockers who obsesses over every little detail, maybe you'll want to mess with it.
It's getting in the way.

The tCK is going to depend on the chipset latency, but let's just try to ignore that for now.

FORMULA:
The formula for period is T = 1/f.

If we take 200 MHz as our example, then T equals 1 divided by 200, which gives us 5ns.

RAS-to-CAS Delay - t(RCD)

It’s usually set to 2T—meaning you're looking at 10 ns based on a 200 MHz FSB (using the formula t(RCD)=2T/200 MHz = 10 ns).

Try to set this value as low as you can possibly go. On most motherboards, the default settings usually sit at (2T, 3T, or 4T).

CAS Latency—better known just as CL—is basically the delay between when your memory controller tells the RAM to grab something and when that data actually starts flowing. Think of it like the "reaction time" of your memory modules. When you're looking at specs, a lower CL number is generally better because it means the latency is shorter. However, it’s not the only thing that matters. You have to look at the whole picture: the clock speed, the voltage, and how stable the system stays under load. It's easy to get caught up chasing the lowest possible latency, but if you push it too hard, you'll just end up with a blue screen instead of a faster PC. If you're planning on overclocking, keep an eye on those timings. Finding that sweet spot where you get snappy performance without crashing your system during a heavy Prime95 run is the ultimate goal.

CL is basically the relationship between tCAC and tCK.
CL = tCAC / tCK (or tCLK)

Basically, tCK stays pretty much constant across the board—on most motherboards, we're looking at 1T (meaning tCK = 1/200MHz = 5ns).
You can calculate the tCAC like this: tCAC = tCK * CL. In this case, that’s 5ns * 2, which gives you 10ns, or basically 2T.

I know all this can feel pretty overwhelming, but if you just take a second to look closely and cross-reference everything with your BIOS, it’s actually not that hard to wrap your head around.
Basically, just look at your current settings to see if your CL is set to 1.5, 2.0, 2.5, or 3.0. You don't actually have to do the math yourself, but here is
an example of how you would calculate everything...

If your RAM can handle it, I’d suggest setting the CL to 2.0. Of course, you'll need to test it—you might even need to bump the voltage up to 2.7 V or slightly lower (depending on what your memory is rated for and how much it can take). If the system won't boot with a specific CL, just back it off to the next highest setting (or whatever stays stable).

Regarding Row Active Delay (tRAS) and Row Cycle Time (tRC):

tRC = min (t(RAS) + t(RP))

If you set the tRAS too high, you're just adding unnecessary latency. On the flip side, if it's too low, the cycles won't complete properly, which can lead to data loss, various instabilities, and other headaches.

The "Golden Formula" for minimum t(RAS) is: min t(RAS) = t(RCD) + CAS + 2 periods
(For my setup, where t(RCD) = 2 and CAS = 2.0, that makes the minimum tRAS = 6)

Recommended Memory Settings:

My advice is to keep those timings as low as possible—meaning CAS Latency, RAS-to-CAS Delay, and RAS Precharge should all be minimized, provided your memory can actually handle it. The only way to know if your RAM is running correctly is to stress test it. There are tons of benchmarking tools and programs out there, many of which are free, and you can find most of them right here:

http://www.2crowded.com/forum/viewf...ed183354b478434

I also highly recommend running a stability test for a full 24 hours just to be sure your system is rock solid. Also, make sure to
check performance within the actual programs and games you play regularly.

So, regarding t(RAS):

min t(RAS) = t(RCD) + CAS + 2T (where CAS is essentially tCAC)
You can calculate tRC as: tRC = min( t(RAS) + t(RP) )
And max t(RAS) = t(RC) - t(RP)

Important Note:

If you have your CAS, RAS-to-CAS, and RAS-Precharge set to 2-2-2, then:

min(tRAS) >= 2 + 2 + 2 = 6
Since tRC is roughly 55 ns or 11T for DR400 memory (using tRC = min(tRAS + tRP)), then:
max t(RAS)
Here’s a quick breakdown of the math:

Since this stuff can get pretty confusing, let me break it down for you:
1.) 2.0-2-2 at 200MHz ->
With CL = 2.0, t(RCD) = 2, and t(RP) = 2:

tCK = 1/200MHz = 5ns,
tCAC = tCK * CL = 5ns * 2.0 = 10 ns = 2T,
This is just verifying that CL = tCAC / tCK = 2T / 1T = 10ns / 5ns = 2.0
min t(RAS) = t(RCD) + CL + 2T = 2 + 2.0 + 2 = 6
tRC = min (t(RAS) + t(RP)) = 6 + 2 = 8 T, or (8 * 5 = 40ns)

2.) 2.0-2-2 at 220MHz ->
With CL = 2.0, t(RCD) = 2, and t(RP) = 2:

tCK = 1/220MHz = 4.545454....ns,
tCAC = tCK * CL = 4.545454... * 2.0 = 9.0909...ns = 2T,
min t(RAS) = t(RCD) + CL + 2T = 2 + 2 + 2 = 6
tRC = min (t(RAS) + t(RP)) = 6 + 2 = 8 T, or (8 * 4.54 = 36.36363636.. ns)

3.) 2.5-3-3 at 200MHz ->
With CL = 2.5, t(RCD) = 3, and t(RP) = 3:

tCK = 1/200MHz = 5 ns,
tCAC = tCK * CL = 5 * 2.5 = 12.5 ns = 2.5T,
min t(RAS) = t(RCD) + CL + 2T = 3 + 2.5 + 2 = 7.5 (so, 8)
tRC = min (t(RAS) + t(RP)) = 8 + 3 = 11 T, or (11 * 5 = 55 ns)

Depending on your tRC and tCK values, that upper limit for tRAS will fluctuate.

I should point out that calculating tRAS is probably the most critical part, since everything else usually stays pretty low—typically 2.0-2-2, 2.5-3-3, or 3.0-3-3, etc.

Adjusting these settings should theoretically boost your bandwidth and overall performance; for instance, an 8 should be better than a 4 in a 2.0-2-2 setup. In theory, there should be proof for that. However, after testing a ton of different configurations, I honestly haven't seen any significant difference on my own rig. Here are all my tests and graphs—the maximum value is highlighted in red in the table. It shows that 4-2-2-2.0 was actually the sweet spot for my specific hardware (motherboard, RAM, etc.), which just proves you really need to test every single setting with various benchmarks... !
Tests available at: http://www.2crowded.com/forum/viewtopic.php?p=1157#1157

Mentioning this article (for the slow learners):
http://webraft.its.unimelb.edu.au/1...ings/index.html (shoutout to MasterFlow)

Hope this helps you out. Enjoy, Kovi!

Raymond Rodriguez40 said:What kind of testing are we even talking about here?

How much bandwidth are you getting at 333MHz versus 500MHz!?
Don't just claim that running 0-0-0-0 latencies at 333MHz somehow beats 3-4-4-10 at 500MHz.

That's just not how it works. On an Intel system, even using dual Channel at 333MHz, you’re looking at a measly 2700 Mb/s under ideal conditions regardless of latency. If you run it at 200 MHz—which hits a 3200 max throughput—the bandwidth is higher even with the worst settings in Single Channel...
What kind of math are you doing? It's faster if the clock speed is higher, right?

We aren't talking about Intel, we're talking about Intel.

The rest of the answer came from Cela.

I guess those aggressive latencies are pretty much useless anyway, since I think you're probably better off just bumping up the memory frequency rather than trying to force it down for tiny, negligible gains

yeah, I'm with you on that..

The difference you get from moving the FSB from 133 to 166 feels way more significant than whatever little boost you might get from tweaking settings from, say, cl2.5 down to cl2

so, like Kovi says... "there's always going to be some kind of sweet spot somewhere" 🙂

dustypilot23 said:I'm with you on that.

The jump from a 133 FSB to a 166 FSB is a massive deal. It’s night and day. Changing your settings from CL2.5 to CL2? That’s barely a dent.

Obviously. That’s a massive 66MHz gap in frequency when you're dealing with DDR.
But you really need to weigh the maximum frequency we can squeeze out using "good" timings against what we get when we push for max speed with "bad" ones.
There aren't any rules here.
It all comes down to the quality of the memory.
You have to play around with things a bit if you want to find that sweet spot. It’s all about experimenting until you hit the optimum.

Honestly, I couldn't stand hearing that people think timings don't matter and that frequency is the only thing that counts. That's just nonsense.

I read that article ages ago—props to Kovi, really—but let’s not forget when it was actually written. DDR400 MHz was just starting to show its face back then, so this isn't exactly relevant anymore... not by a long shot.

Tweaking latencies and obsessing over them... hey, if that's your thing, go for it.
But how much speed are you actually gaining? Speed is nothing without one thing: B A N D W I D T H. Let me say it again: B A N D W I D T H.
It’s not about some weird chemistry or hyper-precise micro-adjustments.
You can tune any RAM module and drop the latencies through the floor—for instance, OCZ 3700 has great timings at 466 MHz... but let's be real, as you saw with Cela during our little debate, 333 MHz won't do you any good if my rig outruns you at 500 Mb/s because it's running at a much higher clock. What people achieve with all that tinkering is a marginal improvement at best. On DDR333, that practically means you're "almost" hitting the maximum bandwidth for that frequency, which is 2700 Mb/s, and not a single millimeter more. All that tweaking is useless if your "pipe" is too narrow... get what I'm saying?
Now, decent low-latency memory costs money. We also have motherboards that handle Intel setups just fine at a 500 MHz FSB, along with memory that (aside from the overpriced stuff) runs at perfectly reasonable latencies at that 500 MHz. At those frequencies, B A N D W I D T H is way more important than having the lowest latencies, and they'll certainly work in SPD mode. It seems a bit silly to buy something like OCZ 4400 and then throttle the FSB (to run synchronously—on Intel) just to chase 1-2-2-5 timings or other "for me" nonsense values that don't actually matter.
At this point, it just comes down to whether the motherboard is high-quality enough to stay stable at a 250 MHz (500) FSB... and very few can actually pull that off. That's why this whole "science" of overclocking exists—it doesn't serve any real purpose other than letting kids argue over whose RAM has lower latencies, while the end result remains irrelevant to them.
If anyone wants to try and tell me my DFI board with OCZ 3700 has worse "who-knows-what" because it runs at 250 FSB instead of 333 MHz with "ultra-low" latencies, they can take their results and shove them. I'm done explaining myself. When they actually manage to hit read speeds over 3500 Mb/s, they can shoot me a PM... maybe then I'll give them a nudge to crank the memory to 400 VDC to actually get some speed.😁

"The OCZ 4400 isn't all that great because it runs at FSB 250... actually, scratch that—my bad. I meant 500 MHz."

Raymond Rodriguez40 said:Look, let’s be real here—as I mentioned to Cela before, having 333MHz doesn't mean a thing if my hardware can pump out 500MB/s because it's running at a much higher clock speed. All that tweaking you're doing just results in some marginal gains. With DDR333, you're basically just trying to hit the maximum bandwidth for that frequency, which is 2700MB/s. You won't get a single millimeter more out of it. Your tuning is useless if your bandwidth bottleneck is already too narrow... you know what I mean?

I hear you, but Sam Evans3 definitely messed up those timings, which wasn't right, and I think everyone else agrees on that. I actually dug up some old screenshots from when I was messing around with this stuff a while back. Obviously, there's a massive difference between an FSB of 333 and 500—no question there—but what's the actual difference between running 333 via SPD versus aggressive 333 settings, or moving up to 400 via SPD?
Here’s a specific example that shows why bumping the FSB is the real winner, but also proves that playing with timings actually helps:

Pcmark01

FSB 333 via SPD 8-4-4-2.5 | CPU 5640, memory 4644
FSB 333 manual 7-3-3-2.5 | CPU 5710, memory 5083
FSB 400 via SPD 8-4-4-2.5 | CPU 6855, memory 5836

So, if we just tighten the timings, we pick up 400 points. If we bump the FSB, we gain 1200 points—that's a third of the total, which is definitely not nothing. If I had something better than PQI, I could probably pull even higher numbers, but the raw digits aren't the main point right now.

Alright, let me drop some actual test results here.

Memory Benchmarks

Just a quick snippet from the report.

2-3% Improvement

Bandwidth matters for the Intel Pentium 4, sure, but it’s not the dealbreaker it used to be back when we were stuck with those old single-channel memory controllers on the i845PE. Things are looking a lot better thanks to the dual Channel support on the i865PE/i875P. On average, the setup running at 400 MHz (with the 5:4 memory divider turned on) and tighter memory timings actually beat out the high-speed memory with loose timings by about 2-3%.

Look, I never said messing with timings doesn't yield improvements—it does. But the real question is when you're actually buying RAM: is it better to grab top-tier, low-latency memory at a lower frequency, or just pick up whatever is cheapest and push it to a higher clock?
That was kind of the point of the discussion, wasn't it?...
Take that A-data DDR500, for instance. It runs fine in both Intel and AMD builds, and it’s cheap. Sure, the latencies are absolute garbage, but since Intel doesn't really take full advantage of their high-speed dual Channel anyway, there’s no point overpaying for massive speed gains that barely show up. If someone actually wants to chase performance on an Intel build, they can go out and buy something like OCZ 4400 that absolutely shreds everything. For AMD, you don't need that overkill; OCZ3700 is plenty, where latency becomes the more important factor at those frequencies...
It’s all well and good to squeeze out extra performance by tweaking settings, but honestly? It’s just too little gain to be worth the headache.

There’s one more thing people overlook: heat. We're talking about differences of a few hundred MB/s depending on the setup. If you tune your memory to run perfectly while it's cold, once things heat up, it starts acting up. It begins skipping cycles because it can't keep up with those aggressive low-latency settings, and suddenly your gaming performance drops right when you need it most.
You should try running a benchmark before and after you've spent an hour torturing the sticks until they're hot...

Why would I bother overclocking a CPU to 2.5 GHz (on an AMD chip) when you get more bang for your buck just by bumping up the FSB synchronously?...
Try raising the FSB while using looser timings instead. See if you get better results at the same CPU frequency—say 2.2 GHz—by running 222x10 versus 200x11 on a standard Barton...

Look, Intel is one thing... but they don't even leverage the memory you set up in a Democratic Party build properly, let alone when you're actually tweaking timings to go lower

I’m sticking to my guns here—those benchmarks you see all over those sites? They're basically just glorified ads
Whether it's Cl2, CL2.5, or CL3... you won't see much difference on AMD, and with Intel, there's practically zero impact