More Core i7 trichannel "failure" from "thiefs"

[JumpingJack]

USB, SATA, etc. are connected to the ICH10. The ICH10 is connected to X58 via a DMI link. So whatever you plug into any USB or SATA will have the limitation of the DMI link, which is much slower than the QPI. Raising the QPI speed won't make any differencies for pheripherals. You don't need more for that anyways.

True ... I was generalizing, even PCIe does not have BW exceeding the QPI ... nothing you do, regardless to the QPI BW will help, the flow of information will be limited elsewhere. Although, I don't recall the BW for the DMI interface between NB/SB, it is probably faster than USB or firewire.

Same thing with HyperTransport. The link to the NB/SB chipsets are not the rate limiters, hence performance will only be retarded if one supresses the HT BW below the BW of the tested link.

[STaRGaZeR]

DMI is equivalent to a 4x PCIe IIRC. However Francois, bingo13 and other people have been saying that increasing the QPI speed is good for the platform, but dunno why because as you say it is not the limiting factor and the only thing that a higher QPI link qould speed up would be something connected to the PCIe lanes of X58, i.e. GPUs...

[justthefax]

Anybody notice the big jump in latency going to tri-channel? Around 15% worse latency

Thanks for the reply.

If I understand correctly, we should all notice the difference between dual and triple channel, but it's very likely that if we use non-multicore applications that the difference will be very small. The bandwidth that is added because of the extra channel is to provide enough bandwidth to fully cover the 8 threads, but is 'overkill' when using in single/dual threaded applications.

Now, that only leaves the everest bandwidth problems. As far as I know, the Lavalys Everest program is quite accurate when it comes to calculating the memory bandwidth and latency, but in tests I've seen the difference still is only 500MB/s:




Only two tests actually show the difference between dual and triple channel, which probably is the correct performance scaling.

[justthefax]

...
For months I've watched you piss on Intel threads and I'm sick of it.
Stay the hell out of the Intel threads since you don't have anything positive to add.

Wow, I got serious deja vu reading this. It's like AMD threads and -------!

[xVeinx]

Anybody notice the big jump in latency going to tri-channel? Around 15% worse latency

And if you look, his timings have changed

[Shintai]

Anybody notice the big jump in latency going to tri-channel? Around 15% worse latency

The clocks and settings of the memory aint the same either.

Plus we dont know the BIOS version.

[JumpingJack]

Anybody notice the big jump in latency going to tri-channel? Around 15% worse latency

Yeah, huge.... trichannel has a whole 25 ns of latency... how terrible.

[JumpingJack]

DMI is equivalent to a 4x PCIe IIRC. However Francois, bingo13 and other people have been saying that increasing the QPI speed is good for the platform, but dunno why because as you say it is not the limiting factor and the only thing that a higher QPI link qould speed up would be something connected to the PCIe lanes of X58, i.e. GPUs...

Well, I cannot be 100% truly certain until I get a CPU I can experiment with myself and see what others do with it. However, I have run numerous HT frequency scaling experiments and it amounts to a hill of nothing in terms of impacting perforamance.

I cannot see QPI being any different. In server, yeah, huge deal... on desktop.... irrelevant. But I could be wrong.

[AuDioFreaK39]

Thanks for the reply.

If I understand correctly, we should all notice the difference between dual and triple channel, but it's very likely that if we use non-multicore applications that the difference will be very small. The bandwidth that is added because of the extra channel is to provide enough bandwidth to fully cover the 8 threads, but is 'overkill' when using in single/dual threaded applications.

Now, that only leaves the everest bandwidth problems. As far as I know, the Lavalys Everest program is quite accurate when it comes to calculating the memory bandwidth and latency, but in tests I've seen the difference still is only 500MB/s:

Why is the CPU 22MHz faster for the dual-channel benchmark and 11MHz faster on the memory than the triple-channel benchmark?



http://xtreview.com/addcomment-id-66...s-SMT-OFF.html


and also, shouldn't the dual-channel benchmark pwn the single much more than this?

[Shintai]

The crysis is loading times. Most of the restriction is HD based.

[Drwho?]

Anybody notice the big jump in latency going to tri-channel? Around 15% worse latency

Actually, the problem is not the hardware here, it is the software, I have my friend Ronen working with the everest guys, I am not sure of the status, but I know from sure that the processor affinities does not allow the max bandwith to be always measured properly.

I will check and update you guys later, Monday.

In the mean time, this 2 numbers shows that Core i7 is the 1st having a real integrated memory controler .. (kidding! don t shoot!)

If you use Sandra, you will see that Banwidth is better with 3.

Francois

[Hornet331]

Yeah, huge.... trichannel has a whole 25 ns of latency... how terrible.

hehe indeed only 230% faster then a current top of the line C2D.

The crysis is loading times. Most of the restriction is HD based.

Isn't it amazing how often those pconline numbers get recycled?

[massman]

it could be early bioses as well who knows

but i would definitely NOT trust software like sandra

32M SuperPi is still the best measure....tapakah is showing a 1% difference with same settings.......that is pretty big for Pi so i'll take it

I'd trust Lavalys/Sandra more than Superpi, to be honest, especially when you want to put a number on the performance scaling of brand new technology. Superpi is good if you want to compare technology you understand, not really that good if you don't know the technology by heart.

Bios release is a possibility, but I can't understand why Intel would send out motherboards that don't feature the benefits of triple channel right away. This is one of the KEY features of the X58/Nehalem platform, it wouldn't make any sense.

In addition, even if the bios isn't ready, why would Intel keep this information internal? They know people will focus on this features, why on earth would they choose for the path that leads to bad publicity when different reviewing websites claim triple channel just doesn't work.

Nvidia 680i gives me almost 100% more bandwidth going from single to dual channel, not sure about Intel chipsets as I have never tested it using Sandra.

Different settings, different results. All I know is that the results of the triple channel that we see now is way too low to be correct. And if they are correct ...

They are so wrong...at least in the tests we ran.

Just got the QPI performance scaling confirmed by another source, so I wonder what tests you ran ;-).

This makes me certain that I'll need a setup myself to test everything out. Why oh why did I pass for the Madshrimps Nehalem coverage ...

Well, NF2 was back in 2002, 6 years ago. Memory bandwidth demand has increased quite alot from those days, and thus the comparison from NF2 is quite much worthless IMO. Besides, I only saw sub 15 % improvements, though, the RAM was cheap kingston and FSB was sub 166 all the time.

Actually, I was comparing with NF2, because that's when I first experienced the benefit of dual channel, just like the Core I7 is the first platform that uses triple channel.

I was running 260+ FSB, maybe not such a fair comparison.

To be honest, I should re-read some reviews to draw a decent conclusion, but I think you get my point when I show you the table with 0% improvement going from dual to triple channel. In the past we always DID notice the bandwidth increasements, 'we' as in the (extreme) overclockers. The fact that we are NOT noticing them at the moment is a sign.

What it boils down to is that most of today's client applications do not produce a demand that exceeds even modest memory bandwidths, aided with a strong cache structure. Increase in BW either by clocking up the bus or increasing memory clocks gives minor improvements, in most cases -- some exceptions are WinRAR's internal benchmark which all it does is read/writes random data to memory while executing it's compression engine... it shows significant sensitivty to BW. I have also seen noteable sensitivity with Mainconcepts H264 encoder.

So, in what Dr. Who? is saying, at 12 GB/s + memory bandwidth is not really going to impact what you observe in real life -- not because the BW is not real, but because the applications used for desktop never deman throughput that exceeds the capabilities.

You will see the BW play an important role in 2S servers, where those applications are more throughput oriented as opposed to client side which are really just task based.

In real-life applications, I don't even worry about dual channel. You're not going to notice anything when opening Internet Explorer or Word, but you will notice when you run resource hungry programs such as video encoding or data compression programs. But isn't the Core I7 / X58 platform designed for the normal end-user? I don't see why you bring up the 2S server example, because it has nothing to do with dual/triple channel working or not.

My question is why we don't see any improvement in benchmarks, which very often extrapolate the differences in performance. When we see differences in benchmark utilities, we can be sure (or not) if technology is working, even at 12GB/s.

Why is the CPU 22MHz faster for the dual-channel benchmark and 11MHz faster on the memory than the triple-channel benchmark?

http://xtreview.com/addcomment-id-66...s-SMT-OFF.html
http://xtreview.com/images/corei712and3chanel06.png

and also, shouldn't the dual-channel benchmark pwn the single much more than this?

No idea why they are not clocked exactly the same, not my benchmarks anyway. The small difference in frequency is NOT the reason why the differences in performance are this small, though ;-).

And yeah, the xtreview benchmarks are screwed, I think.

[massman]

The crysis is loading times. Most of the restriction is HD based.

Seriously? I don't really find that a propper way to compare hardware, although these are more real-life measurements than raw numbers.

Actually, the problem is not the hardware here, it is the software, I have my friend Ronen working with the everest guys, I am not sure of the status, but I know from sure that the processor affinities does not allow the max bandwith to be always measured properly.

Good, let's hope the preliminary support gets turned into full support sooner than later.

[Drwho?]

I'd trust Lavalys/Sandra more than Superpi, to be honest, especially when you want to put a number on the performance scaling of brand new technology. Superpi is good if you want to compare technology you understand, not really that good if you don't know the technology by heart.

Bios release is a possibility, but I can't understand why Intel would send out motherboards that don't feature the benefits of triple channel right away. This is one of the KEY features of the X58/Nehalem platform, it wouldn't make any sense.

In addition, even if the bios isn't ready, why would Intel keep this information internal? They know people will focus on this features, why on earth would they choose for the path that leads to bad publicity when different reviewing websites claim triple channel just doesn't work.



Different settings, different results. All I know is that the results of the triple channel that we see now is way too low to be correct. And if they are correct ...



Just got the QPI performance scaling confirmed by another source, so I wonder what tests you ran ;-).

This makes me certain that I'll need a setup myself to test everything out. Why oh why did I pass for the Madshrimps Nehalem coverage ...



Actually, I was comparing with NF2, because that's when I first experienced the benefit of dual channel, just like the Core I7 is the first platform that uses triple channel.

I was running 260+ FSB, maybe not such a fair comparison.

To be honest, I should re-read some reviews to draw a decent conclusion, but I think you get my point when I show you the table with 0% improvement going from dual to triple channel. In the past we always DID notice the bandwidth increasements, 'we' as in the (extreme) overclockers. The fact that we are NOT noticing them at the moment is a sign.



In real-life applications, I don't even worry about dual channel. You're not going to notice anything when opening Internet Explorer or Word, but you will notice when you run resource hungry programs such as video encoding or data compression programs. But isn't the Core I7 / X58 platform designed for the normal end-user? I don't see why you bring up the 2S server example, because it has nothing to do with dual/triple channel working or not.

My question is why we don't see any improvement in benchmarks, which very often extrapolate the differences in performance. When we see differences in benchmark utilities, we can be sure (or not) if technology is working, even at 12GB/s.



No idea why they are not clocked exactly the same, not my benchmarks anyway. The small difference in frequency is NOT the reason why the differences in performance are this small, though ;-).

And yeah, the xtreview benchmarks are screwed, I think.

You got a very valid point, only the people with access to the official press kit can access to the lastest BIOS, this one has a very important patch for the memory controler. If you use a prototype of Smackover, without this bios (version has to be superior of 2000), you are not optimum
For other motherboard maker, make sure you get the latest BIOS released this week.

[massman]

Hehe, at the moment I was reading your reply, a good friend (who's finishing up his review) told me he updated his bios to the latest version and indeed noticed the increase in bandwidth when using sandra: single-9G, dual-16G and triple-20G (stock 965, 1333 7-7-7-18). Close to no difference in real-life apps, though .

[Shintai]

Seriously? I don't really find that a propper way to compare hardware, although these are more real-life measurements than raw numbers.

Yes, seriously. xtreview just stole the numbers and posted it as their own. (And thereby completely skipping all explanations).

But as said, you can read it yourself.



Also a note that this aint benched on the newest versions to say it mildly.

[Drwho?]

Hehe, at the moment I was reading your reply, a good friend (who's finishing up his review) told me he updated his bios to the latest version and indeed noticed the increase in bandwidth when using sandra: single-9G, dual-16G and triple-20G (stock 965, 1400 7-7-7-18). Close to no difference in real-life apps, though .

This prove one thing ... I was not lieing to you guys when I was telling you that memory controler on dice was not making a big difference for AMD ...

Now, mainstream will have around 20 G/s, that means, programmers will start using it.
Take a look at the speed of Power Director, and you ll see a difference

[Drwho?]

ok, so, after checking, here is the answer from the architect himself (Ronak).

Everest is not threaded for the memory test, I verified with a Skulltrail 4.0Ghz and a Nehalem Big time OC, and both of them use 25% of the CPU during the test.
Memory bandwidth is so great in Nehalem that you need more than a single threaded test to measure fully the memory bandwidth.

Please use sandra for the time being, Everest will catch up soon I think.

Francois Piednoel
Intel Corp.

[xVeinx]

Thanks for finding out the details for us!!!

[eva2000]

ok, so, after checking, here is the answer from the architect himself (Ronak).

Everest is not threaded for the memory test, I verified with a Skulltrail 4.0Ghz and a Nehalem Big time OC, and both of them use 25% of the CPU during the test.
Memory bandwidth is so great in Nehalem that you need more than a single threaded test to measure fully the memory bandwidth.

Please use sandra for the time being, Everest will catch up soon I think.

Francois Piednoel
Intel Corp.

Thanks for that bit of info

[Loque]

why the more channels are used, the loading times get worse ? (as in that crysis test)

[Drwho?]

why the more channels are used, the loading times get worse ? (as in that crysis test)

Check with Sandra, you ll see that it does not have this problem either , Sandra knows nehalem, but everest does not.
We changed the way you are suppose to measure few thinks, due to the changes in frequency added in the turbo mode.
measuring frequency for example became more complexe, because the power controle unit is changing it very fast on the fly, and cores go to powersaving fast.

Everest is very close to the metal, because if this, it needs some adjustment.

For Frequency, you can trust CPUz 1.48

For Crysis well, the numbers look right to me ... more channel is faster.

[Hornet331]

why the more channels are used, the loading times get worse ? (as in that crysis test)

lol wut?

loading time gest faster.... singel -> ~30secs, dual -> 26secs, tripple 24secs....

[Loque]

lol wut?

loading time gest faster.... singel -> ~30secs, dual -> 26secs, tripple 24secs....

oh snap nvm, must not post at 2:50 am