Jump to content
HWBOT Community Forums

s1366 high memory clock submissions


Recommended Posts

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 by TaPaKaH
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Retesting atm :


X58 OC board


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 . :)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 :D

Link to comment
Share on other sites

  • Crew

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 by Leeghoofd
Link to comment
Share on other sites

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 by I.nfraR.ed
Link to comment
Share on other sites

  • Crew

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



Link to comment
Share on other sites

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 :D), 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 by I.nfraR.ed
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...