Memory bandwidth maxed out?

[RJ]

I've got 2 512 sticks of A-Data DDR2-800 memory. I'm overclocked @ 400 mhz, and my mem divider is @ 1:1.

My problem is that when I run memtest86 @ 9x400, I get an error or two in Test 7, Random Memory Sequence. I messed with voltages... up, down, sideways. I messed with the timings, 4-4-4-12, 5-5-5-15, 5-5-5-18, 5-6-6-20. When I run the same test @ 8x400, no errors what-so-ever. I see that the memory bandwidth increases with the OC, even though the memory maintains its 400 mhz speed. According to memtest86, it goes from 15650 mb/s @ 2.4 ghz, to 23526 mb/s @ 3.6 ghz. Now there are no noticable problems running the comp @ 3.6 ghz, runs all tests no problem. I like to be thorough when I OC, so that's why I ran memtest86. Getting that error kinda bugs me. I'm currently running 3.2 ghz just so I know everything's kosher.

Is it possible a particular memory can only handle so much bandwidth? I've bumped the mem clock up to as high as 440 mhz @ lower OC's, so I know the memory can handle a higher speed. Is it the memory controller? I've seen where my mobo has been OC'ed over 450 mhz.

I do know that increasing the clock has an effect on memory bandwidth....SiSanda shows it going from in the 5000s stock to the 7000s OC'ed to 3.6 ghz.

This memory is temporarily part of my system until I get 2x 1024 mb sticks of either 1000 or 1066 memory. It's going back into my G965 HTPC where it won't see these speeds due to lack of voltage settings.

Any thoughts on whether the memory or mem controller are bandwidth limited?

Thanks 8)

 

[Mondoman]

I've got 2 512 sticks of A-Data DDR2-800 memory. I'm overclocked @ 400 mhz,

I'm assuming you mean your FSB is at 400MHz, since 400MHz is the rated clock speed for DDR2-800 memory.

My problem is that when I run memtest86 @ 9x400

I assume you mean your CPU is at 9x the 400MHz FSB clock (3600MHz internaly).

I get an error or two in Test 7, Random Memory Sequence.... When I run the same test @ 8x400, no errors what-so-ever.

OK, sounds like you've found a limit to how fast you can OC your CPU.

I see that the memory bandwidth increases with the OC, even though the memory maintains its 400 mhz speed.

Perhaps you are misinterpreting the memtest86+ display. The cache memory on the CPU chip runs at the internal CPU speed (that's the first two rows of bandwidth). However, the main RAM (3rd line) runs at the memory bus speed.

Now there are no noticable problems running the comp @ 3.6 ghz, runs all tests no problem.

But you said above that you get errors in memtest86+ at 9x00=3.6GHz!

I'm currently running 3.2 ghz just so I know everything's kosher.

Sounds good. I'd run Orthos (or PRIME95, depending on how many cores you have) under Windows for a more stringent test before settling on a kosher speed.

...
Any thoughts on whether the memory or mem controller are bandwidth limited? ...

Without knowing what type of CPU you have and what model number MB you have, we can't really make informed responses.

 

[Mondoman]

OK, saw your specs in the sig now (it's very annoying that they don't show up in the "Topic Review"!).
Assuming you are running in dual-channel mode, your memory bandwidth is DDR2-800 x 2 (dual channel) = 1600MHz data rate. Your CPU FSB can handle up to 400MHz clock x 4 (quad-pumped) = 1600MHz data rate. Thus, your memory is saturating your CPU's available bandwidth.

 

[RJ]

I've got 2 512 sticks of A-Data DDR2-800 memory. I'm overclocked @ 400 mhz,

I'm assuming you mean your FSB is at 400MHz, since 400MHz is the rated clock speed for DDR2-800 memory.

My problem is that when I run memtest86 @ 9x400

I assume you mean your CPU is at 9x the 400MHz FSB clock (3600MHz internaly).

I get an error or two in Test 7, Random Memory Sequence.... When I run the same test @ 8x400, no errors what-so-ever.

OK, sounds like you've found a limit to how fast you can OC your CPU.

I see that the memory bandwidth increases with the OC, even though the memory maintains its 400 mhz speed.

Perhaps you are misinterpreting the memtest86+ display. The cache memory on the CPU chip runs at the internal CPU speed (that's the first two rows of bandwidth). However, the main RAM (3rd line) runs at the memory bus speed.

Now there are no noticable problems running the comp @ 3.6 ghz, runs all tests no problem.

But you said above that you get errors in memtest86+ at 9x00=3.6GHz!

I'm currently running 3.2 ghz just so I know everything's kosher.

Sounds good. I'd run Orthos (or PRIME95, depending on how many cores you have) under Windows for a more stringent test before settling on a kosher speed.

...
Any thoughts on whether the memory or mem controller are bandwidth limited? ...

Without knowing what type of CPU you have and what model number MB you have, we can't really make informed responses.

Is your middle name Richard?

I know how to read memtest86 stats. The FSB is NOT 400, the cpu clock is 400 mhz, the FSB is 1600 mhz. You run Prime95, SiSandra, super pi, 3DMark, PCMark, etc in the OS. Memtest86 is it's own program and runs OUTSIDE of Windows. If you take the time to read my SIG and not concentrate on sentence structure, you would have noticed that all the info is SITTING RIGHT THERE! What, no spelling corrections? 8O

thanks dick!

 

[Mondoman]

Sorry if I came off as impolite; it wasn't intended. Just trying to make sure we're both on the same page; no need for any raised hackles.

...
I know how to read memtest86 stats.

Ok, I think I understand now. I thought you were saying that the memory bandwidth increased as you increased the OC from 8x400 to 9x400, which of course it doesn't. Rereading your post, I'm guessing you were saying that it increased as you increased the FSB clock from 266 to 400MHz, which of course it does, since data from memory has to go through the FSB, and under your conditions, the FSB is the bandwidth limiting stage.

The FSB is NOT 400, the cpu clock is 400 mhz, the FSB is 1600 mhz.

Technically, the FSB is *clocked* at 400MHz; since data is transferred 4 times per cycle, effective *data throughput* is 1600MHz.

You run Prime95, SiSandra, super pi, 3DMark, PCMark, etc in the OS. Memtest86 is it's own program and runs OUTSIDE of Windows.

Yes, exactly. That's why I suggested running Windows-based tests like Orthos/PRIME95 only after you're sure the basics are working OK with memtest86+.

If you take the time to read my SIG ...you would have noticed that all the info is SITTING RIGHT THERE! ...

Yes, hence my apology at the start of the 2nd post I made a few moments later.

Was there anything else?

 

[RJ]

Ok, I think I understand now. I thought you were saying that the memory bandwidth increased as you increased the OC from 8x400 to 9x400, which of course it doesn't. Rereading your post, I'm guessing you were saying that it increased as you increased the FSB clock from 266 to 400MHz, which of course it does, since data from memory has to go through the FSB, and under your conditions, the FSB is the bandwidth limiting stage.

But according to memtest86, If I run it with my CPU @ 6x400, I show 15k mb/s. When I run @ 9x400, the number jumps to 23.5k mb/s. that's why I'm scratching my head. How does the multiplier effect the memory bandwidth? The Memory divider remains @ 1:1, so theoretically it's at stock speed when I leave the CPU clock @ 400 mhz.

Ill run it at 7x and 8x to see what numbers they post as well as SiSandra's memory bandwidth test at those multipliers. BRB

 

[RJ]

Okay...
Memtest86 shows the memory bandwidth to be...
6x400...15650 mb/s
7x400...20109 mb/s
8x400...23526 mb/s
9x400...23526 mb/s

SiSandra shows the memory bandwidth to be...

6x400...6518
7x400...6901
8x400...7013
9x400...7098

Now both tests show a considerable jump between 6 and 7. It then creeps from 7 to 8 to 9.
I'd think that shows a bottleneck somewhere. Anyone else show similar #'s with an E6600? I'd like to figure out if it's the memory or the memory controller.

Thanks in advance.

 

[Mondoman]

Strange. The memtest numbers you're getting are pretty much what I would expect to see for on-chip cache at full processor speed, while the Sandra numbers are more what I would expect for main memory. Perhaps memtest86+ isn't recognizing your hardware quite right. I like PC Wizard 2007; under Benchmark on the left panel, the "MEM" benchmark tests bandwidth for memory transfers from a few k to megs and plots out the results. You can easily see where the cache runs out, etc.

 

[RJ]

There is a cache speed shown in memtest86. I'm definitely referencing the memory stat.

 

[wimcle]

My guess is memtest86 is computing that speed based on an actual write then read of x number of bytes to mem (not just fsb multiplied by width).

Thus there will be some cache effect, even if the read/writes are pseudorandom , thats why 3.6Ghz is marginally faster than 3.2Ghz.

 

[SuperFly03]

RJ, do me a favor, try MemTest86 at 405x9 not 400x9.

The reason is that there are inherent straps in the north bridge and on the 965 chipset the strap changes at 400, also from 360-400 *if I remember* your memory is generally less stable and more prone to errors in tests like MemTest. If you knock it up a notch to 405, that should cause the new strap to kick in and you should pass Memtest.

Source: Techrepository

One other thing is 400fsb has an added tweak. 399fsb had memtest bandwidth of 4799MB's but was completely unstable, 400fsb had bandwidth of 4812MB/s and was completely stable... but as soon as I moved to 401fsb bandwidth shot down to 4324MB/s.
This situation reminds me of the old P4P800 turbo mode at 200fsb where Asus forced PAT and a latency change on the chipset to make the boards look good for reviews. I have a feeling the 1333 strap is forced at 400fsb but the latency we see at 1067 strap is still in play maybe...so it may be worth setting 400fsb, boot to windows and clock higher with clockgen for benchmark runs with this board

To finish...if you are clocking 1:1 I seriously suggest you skip 360 to 400fsb and push up from 401, the errors you see are NB related and not the memory in most cases.

So I tend to agree with Mondo, your bandwidth sounds pretty darn high for memory.

 

[RJ]

RJ, do me a favor, try MemTest86 at 405x9 not 400x9.

The reason is that there are inherent straps in the north bridge and on the 965 chipset the strap changes at 400, also from 360-400 *if I remember* your memory is generally less stable and more prone to errors in tests like MemTest. If you knock it up a notch to 405, that should cause the new strap to kick in and you should pass Memtest.

Source: Techrepository

One other thing is 400fsb has an added tweak. 399fsb had memtest bandwidth of 4799MB's but was completely unstable, 400fsb had bandwidth of 4812MB/s and was completely stable... but as soon as I moved to 401fsb bandwidth shot down to 4324MB/s.
This situation reminds me of the old P4P800 turbo mode at 200fsb where Asus forced PAT and a latency change on the chipset to make the boards look good for reviews. I have a feeling the 1333 strap is forced at 400fsb but the latency we see at 1067 strap is still in play maybe...so it may be worth setting 400fsb, boot to windows and clock higher with clockgen for benchmark runs with this board

To finish...if you are clocking 1:1 I seriously suggest you skip 360 to 400fsb and push up from 401, the errors you see are NB related and not the memory in most cases.

So I tend to agree with Mondo, your bandwidth sounds pretty darn high for memory.

You are da sh*t!

405x9...23831 mb/s memory, L1 59747 mb/s
NO ERRORS!

I'm relatively new to the dark side(Intel), so I'm still learning the quirks.

Thanks for the fix.

 

[RJ]

After reading that article you linked, I dropped down to 7x405, and sure enough, my reported fsb jumped to 4x521, 2084 mhz data rate. With 9x405, it was reading 4x405, 1620 mhz data rate. That's some wild sh*t!

Slowing your computer makes it faster. Let me take about an hour or two to wrap my head around that one.

Thanks again for the link and the suggestion.

 

[SuperFly03]

You are welcome. Freecableguy is an extremely smart guy. I couldn't have figured that crap out myself but I can use his discovery and understand it. It is some weird stuff.

GL have don't have too much fun with that OC

Careful changing the multiplier from the default. If you read the entire article you'll noticed it actually OC's your NB... weird huh?

 

[RJ]

You are welcome. Freecableguy is an extremely smart guy. I couldn't have figured that crap out myself but I can use his discovery and understand it. It is some weird stuff.

GL have don't have too much fun with that OC

Careful changing the multiplier from the default. If you read the entire article you'll noticed it actually OC's your NB... weird huh?

I was wondering why I couldn't get a boot in the 400s when I kicked the multi down to 6x. Now I know I was killing the NB fsb :idea:

I'm playing right now. I've got better results @ 8x450 than I did with 9x400, and they're both theoretically 3.6ghz. SiSandra shows that the CPU is actually working at a nice 4.05ghz and my NB fsb is at 506, instead of the 450 I set. Pretty frickin cool!

I'm glad to see that my memory can handle DDR2-900. Sisandra shows it at 1012 mhz data rate. I did drop the timings to 5-5-5-15 from 4-4-4-12, just to be safe.

Thanks again for passing on the math lesson.....definitely worth spending a saturday afternoon starting and restarting my comp