s1366 high memory clock submissions

[TaPaKaH]

I always thought that with s1366 there's a minimum uncore frequency required to achieve certain memory frequency. More precisely, 3*memclock for 32nm CPUs and 4*memclock for 45nm CPUs. But some scores from recent Country Cup have got me confused.

 

some submissions just for reference, no particular stress

http://hwbot.org/submission/2236164 (32nm, mem multi 9, uncore multi 18, should be 27)

http://hwbot.org/submission/2235703 (32nm, mem multi 8, uncore multi 22, should be 24)

http://hwbot.org/submission/2236313 (45nm, mem multi 6, uncore multi 20, should be 24)

 

May be the new gen s1366 boards have special options and are able to break that "rule".

Might as well be a readout error by CPUz (obviously on the memfreq side, 6GHz uncore on a Bloomfield would be ridicilous).

 

What do others think ?

Edited December 30, 2011 by TaPaKaH

[Leeghoofd]

I was surprised too Sam when I could select them dividers... since my CPU is not stellar in uncore ( caps at 4.2 Ghz under LN2 lol ) I opted to go for this divider... board X58 OC... normal uncore for these speeds should be 4.1Ghz...

[TaPaKaH]

yes, just noticed that all the "interesting" results are made using the X58A-OC

 

At least on ASUS, when you went from, say x18 to x17 uncore multi on a Gulftown, the board would automatically switch mems from x6 to x5 and there was no way you could get x17/x6 to work.

[Hondacity]

i'll test this out.. seems nice to have use for an orange board.

[Mikecdm]

Interesting indeed and I'm the one who didn't realize that the 920 had a 12x memory multi

[Leeghoofd]

Retesting atm :

 

X58 OC board

990X

Corsair GTX2

 

1) with triple channel it doesn't work : no post

 

2) Dual channel I can boot at a 1:1 ratio uncore ram speed, not lower...

 

will provide screenies later on... testing 133 bclock 2133 ram divider

[Stelaras]

Retesting atm :

 

X58 OC board

990X

Corsair GTX2

 

1) with triple channel it doesn't work : no post

 

2) Dual channel I can boot at a 1:1 ratio uncore ram speed, not lower...

 

will provide screenies later on... testing 133 bclock 2133 ram divider

 

 

I'll try to test it again next week .

 

Keep us informed .

[GunGod]

Something is not ok for sure! But i don't have GB mobo to test it and i start to think that some ppl have the rights to be upset.

Found something similar again with gigabyte board here:

http://hwbot.org/submission/2212344_thl_memory_clock_ddr3_sdram_1521_mhz

[Massman]

Hm. You guys think the memory frequency that CPU-Z is reporting isn't the real memory frequency?

[TaPaKaH]

Yes, it doesn't seem to misreport the uncore since 1566*4 would just not be possible on a Bloomfield.

 

I'd like someone with a Gigabyte board to measure perf (32M, Everest) with various memory dividers using constant BCLK and uncore multiplier. If, with mem going above uncore/3 or uncore/4, the performance doesn't get better - it's either limited by the uncore (running single channel should focus on memory performance a bit more) or the frequency is just being misreported.

[I.nfraR.ed]

Yes, someone should do something similar to the research I did for CL4 DDR3, but with dividers.

 

http://hwbot.org/submission/2212232_i.nfrar.ed_memory_clock_ddr3_sdram_1167.9_mhz

[Massman]

Hm, okay, possible disaster I'd say.

 

It's the only option, though. I don't think there's a way around the CPU limitations.

[GunGod]

Hm. You guys think the memory frequency that CPU-Z is reporting isn't the real memory frequency?

 

Unfortunately yes, till now it is only with Gigabyte boards. I think it is bios related, and it lower automaticaly the mem freq. according ucore ratio specification. Ill try get mobo and prove it

 

 

 

Hm, okay, possible disaster I'd say.

 

I dont want to be in ur place atm

[knopflerbruce]

Not the best news, but IMO we have no choice but to remove the scores done with the wrong dividers.

[Stelaras]

How do you know that the scores that doesn't show the cpu-z screenshots are valid ?

 

We should first do some tests and afterwards decide what should be done.

 

Also , i think that it should be mandatory to have all the cpu-z screenshots also .

[Leeghoofd]

I tested the different uncores and they seem correctly in balance...

[Massman]

What do you mean by tested and balanced?

[Leeghoofd]

That I get a far higher score with the higher uncore speeds (tested in superpi32m and AIDAI64) If it proves if the rams are really at that speed that is another thing. I leave that for the pros...

 

Have to look for the screenshots on the USB key, forgot to up them

Edited January 4, 2012 by Leeghoofd

[Massman]

Awaiting all the screens

[Leeghoofd]

 

As it should be according Intel specs...

 

How you can force the uncore down with X58-OC

 

 

Will try to test with 1422 ram dual channel and 2133 uncore to see if we get the same outcome in pi and Aida

Edited January 6, 2012 by Leeghoofd

[I.nfraR.ed]

You can test also if it's possible to tighten the timings more in the second case when compared to the first one.

If that's a MGH-E based memory, you should be able to run 1422 5-5-5 or 5-6-5.

In fact you should be able to pull tighter timings in the second case, regardless the memory chips used, if the real frequency is ~710.

Edited January 6, 2012 by I.nfraR.ed

[Massman]

Okay, from what I can distilate from the two screens, it seems that the frequencies are indeed being reported correctly. Actually, it all makes perfect sense. Hint: http://www.madshrimps.be/vbulletin/f39/mass-uclk-technical-limitations-useful-marketing-tool-65573/

[Leeghoofd]

K Theory one :

 

designated ram clock is false and should be 1422Mhz in reality. ( this to stay in sync with the 2133Mhz uncore )

 

 

11min 07 for 1428Mhz vs 10min 53sec for 2133Mhz speeds = +/- same uncore speeds and CPU Mhz

 

 

So in my humble opinion : ram speed is correct, but who am I

 

Quick run with upped uncore speeds, speed increase is dramatic

 

[I.nfraR.ed]

Okay, from what I can distilate from the two screens, it seems that the frequencies are indeed being reported correctly. Actually, it all makes perfect sense. Hint: http://www.madshrimps.be/vbulletin/f39/mass-uclk-technical-limitations-useful-marketing-tool-65573/

 

Don't have enough time to read the whole thread there right now (and more important - understand it ), but I was actually thinking about an analogy with AMD ratios. So, bottom line, it seems that mainboard vendors artificially disable the possibility to run "out of sync" until now?

Edited January 6, 2012 by I.nfraR.ed

[Massman]

Not artificially, I'm sure that in Intel specs this will be guidelined like this.

 

The explanation is really simple: each memory channel represent 64bit of data. In triple channel, that means there's 192bit of data available each clock tick. The IMC in the cpu is not 192bit width (technical design limitation), so you need to run the IMC faster than 1:1 if you want to transfer that 192bit as fast as possible. All cpus based on Nehalem design are basically the same architecture, but just with different characteristics like # cores and # of adresseable channels. The more cores you have, the more imc width you have, thus the more data you can grab per clock cycle.

 

For a 4c nehalem design and triple channel, the lower limitation is 1:2. Why? 4 cores = 4x24bit imc and triple channel = 3x64bit interface. So, if you have imc at 2x speed of memory, you can adress 2x4x24bit data with 2 imc clks and one dram clk. So: 8x24bit = 192bit and 3x64bit = 192bit too. That is like Bloomfield!

 

For a 4c nehalem design and dual channel (like Lynnfield), the limitation is 2:3. Why? 4 cores = 4x24bit imc and dual channel = 2x64bit. If you have IMC at 1,5x speed of memory, you can address 3x4x24bit data with 3 imc clk in 2 dram clk. So: 3x4x24bit = 288bit and 2x2x64bit = 256bit. In this scenario, you have a bit of "imc clk" left, but that has got to do with proper alignment ("it's easier to split a 192 block in 2x 96 bit than in 3x 64").

 

You can make the same exercise for Gulftown.

 

All other boards just stuck with the default limitations of Intel spec, but it seems that the X58A-OC board is actually working with all the different combinations as long as the alignment is ok. So, any combination of # cores and # of channels you set has a different ratio limitations. Pretty nice, actually!!

 

//EDIT: Urgh, this does not look understandible at all. Let me try again.

 

For all Nehalem/Westmere family;

 

- 2 cores = 48bit cpu-imc interconnect

- 4 cores = 96bit cpu-imc interconnect

- 6 cores = 144bit cpu-imc interconnect

 

- single channel = 1x 64bit = 64bit = 2x 32bit (for easy alignment at 1/2)

- dual channel = 2x 64bit = 128bit = 2x 64bit (for easy alignment at 1/2)

- triple channel = 3x 64bit = 192bit = 2x 96bit (for easy alignment at 1/2)

 

So, for

 

- 2C-TC: 1x 192bit = 4x 48bit => 1:4 => DDR3-2000 must have 8000 MHz uncore (/)

- 2C-DC: 3x 128bit = 8x 48bit => 3:8 => DDR3-2000 must have 5333 MHz uncore (/)

- 2C-TC: 3x 64bit = 4x 48bit => 3:4 => DDR3-2000 must have 2666 MHz IMC (*)

 

- 4C-TC: 1x 192bit = 2x 96bit => 1:2 => DDR3-2000 must have 4000 MHz IMC (Bloomfield)

- 4C-DC: 3x 128bit = 4x 96bit => 3:4 => DDR3-2000 must have 2666 MHz IMC (Lynnfield) (*)

- 4C-SC: 3x 64bit = 2x 96bit => 3:2 => DDR3-2000 must have 1333 MHz IMC (/) (*2)

 

- 6C-TC: 3x 192bit = 4x 144bit => 3:4 => DDR3-2000 must have 2666 MHz IMC (Gulftown) (*)

- 6C-DC: 9x 128bit = 8x 144bit => 9:8 => DDR3-2000 must have 1777 MHz IMC (/) (*2)

- 6C-SC: 9x 128bit = 4x 144bit => 9:4 => DDR3-2000 must have 888 MHz IMC (/) (*2)

 

(*): problem with alignment if you use 3:4 ratio, it's easier to use 2:3 and just leave some IMCclk unused (info).

(*2): I guess theoretically you can have uncore lower than memory clock, but I assume there are other limitations that prevent IMC to be clocked lower than DRAM. Maybe related to cache. So, in practice you can't go below 1:1.

 

The above configuration counts for native xCore parts. Most of the combinations were never released. For instance, if they would have made a native 2core Nehalem with triple channel support, they would've needed an uncore part clocked at 8000MHz to support DDR3-2000. Practically, that would mean Intel would've spec'd that part as DDR3-800 max or so (3200MHz IMC). The advantage of a native 6core CPU like Gulftown is that there's always a 144bit IMC present, so can easily run 1:1 with uncore.

 

Does this make sense?