Nehalem Clocks and Turbo Mode

[Idontcare]

Originally posted by: dmens

Originally posted by: Idontcare
I love this feature of Nehalem...but everytime I have seen it discussed on XS forums the Intel employees come out and state that it is solely for laptops/mobile platforms and won't be activated for desktop Nehalems.

LOL that's BS.

Thanks for confirming, I am happy to hear this.

 

[virtualrain]

Originally posted by: Idontcare

Originally posted by: Dadofamunky
How can Nehalem possibly have a lower transistor count? After all, it has an IMC and the likelihoof of what, 4 cores to start? Of course, those must be Intel's numbers so I'm sure they're right... Would it be because having the IMC enables Intel to cut back on the on-die L2 cache?

Consider that the Yorkfield which is quoted for the 800+M xtors has 12MB of L2$...whereas Bloomfield Nehalem has 8MB of L3$ and 1MB of L2$...so just in having 3MB less cache that's going to add back a ton of xtors to the budget.

http://chip-architect.com/news/Shanghai_Nehalem.jpg

But don't be fooled into just looking at the xtor counts...note the die-size has ballooned. Yorkfield has an aggregate diesize of 214mm^2 whereas Bloomfield Nehalem weighs in at 246mm^2...Nehalem has 89% of the transistors as Yorkfield but is 15% larger in diesize.

Exactly, the reduction in transistors comes from the reduction in L3 and L2 cache sizes which are no longer needed with the on-die IMC. And while the die size of Nehalem is bigger, you need to keep in mind that a good chunk of the NB is now on-die.

It will be interesting to speculate what factors of the Nehalem design will be advantageous to overclocking vs. holding us back. For example, not having to contend with FSB GTL biasing will be a huge benefit. What else?

 

[dmens]

Originally posted by: virtualrain
It will be interesting to speculate what factors of the Nehalem design will be advantageous to overclocking vs. holding us back. For example, not having to contend with FSB GTL biasing will be a huge benefit. What else?

QPI has biasing too. But it has no significant effect on overclocking.

IMO, the fact that all CPU's must be validated to function properly even in "permanent" turbo mode will be a big gain for overclockers because they will be able to eat up that easy, pre-validated margin.

 

[virtualrain]

Originally posted by: dmens

Originally posted by: virtualrain
It will be interesting to speculate what factors of the Nehalem design will be advantageous to overclocking vs. holding us back. For example, not having to contend with FSB GTL biasing will be a huge benefit. What else?

QPI has biasing too. But it has no significant effect on overclocking.

IMO, the fact that all CPU's must be validated to function properly even in "permanent" turbo mode will be a big gain for overclockers because they will be able to eat up that easy, pre-validated margin.

Good points.

As someone else pointed out earlier, yields may play a factor in holding OC'ing back. The initial highest binned parts might be a real lottery as to how well they overclock. Some might be gold and clock to 4GHz easily while others might struggle to overclock at all. I'm guessing that buying a lower binned part initially will mean limited overclocking otherwise it likely would have been binned higher. Does this make sense?

A big unknown is how the integrated memory controller will affect overclocking... it all depends on how it's implemented and what controls overclockers will have in isolating it from the equation I'm guessing.

 

[Dadofamunky]

Originally posted by: Idontcare

Originally posted by: Dadofamunky
How can Nehalem possibly have a lower transistor count? After all, it has an IMC and the likelihoof of what, 4 cores to start? Of course, those must be Intel's numbers so I'm sure they're right... Would it be because having the IMC enables Intel to cut back on the on-die L2 cache?

Consider that the Yorkfield which is quoted for the 800+M xtors has 12MB of L2$...whereas Bloomfield Nehalem has 8MB of L3$ and 1MB of L2$...so just in having 3MB less cache that's going to add back a ton of xtors to the budget.

http://chip-architect.com/news/Shanghai_Nehalem.jpg

But don't be fooled into just looking at the xtor counts...note the die-size has ballooned. Yorkfield has an aggregate diesize of 214mm^2 whereas Bloomfield Nehalem weighs in at 246mm^2...Nehalem has 89% of the transistors as Yorkfield but is 15% larger in diesize.

Yeah, that makes sense.

I'll admit, I'm not planning on moving over to that platform for some time. I'll get a Q6700 or a 45nm quad over the next year or so and probably stand pat for some time. I don't see the benefit of switching to a new platform right away, especially with the socket confusion that others have alluded to.

 

[bryanW1995]

I'd bet that oc'ing on the nehalem will be more complicated than lga 775's...probably more like on amd's right now.

 

[virtualrain]

Originally posted by: bryanW1995
I'd bet that oc'ing on the nehalem will be more complicated than lga 775's...probably more like on amd's right now.

How is overclocking difficult on AMD's right now? I haven't overclocked an AMD since the original X2 a few years ago and it was pretty simple then... although the memory speed was linked to the processor speed which was a pain, it wasn't that difficult.

Overclocking quad's on Intel has been painful from the point of view that to get max overclocks you need to have a lucky NB, you have to tweak a variety of different voltages, GTL bias on both dies and the NB, etc. I couldn't imagine overclocking being more difficult than Kenstfield.

 

[Idontcare]

Originally posted by: dmens
IMO, the fact that all CPU's must be validated to function properly even in "permanent" turbo mode will be a big gain for overclockers because they will be able to eat up that easy, pre-validated margin.

Oh now you are just needlessly arousing me...stop with the sweet talk already!

I'm ready for some Bloomfield action! Bring on the chips!

 

[Nemesis 1]

I am excited about penryn . BUT! Nehalem and the time frame of its arrival reaaly makes one stop and Think . SSD drives should be cheaper/ DDR3 should be cheaper. New GPU's from ATI /NV. Nehalem looks to be a complete system rebuild. used with SSD. It should be a whole new ballgame. I have a kent. No way am I upgrading till nehalem . I was on a p4c and dothan before C2D and I can wait a few cheesey months for Nehalem.

 

[bryanW1995]

well, that's true. they're both pretty complicated these days.

 

[bryanW1995]

Originally posted by: Idontcare

Originally posted by: dmens
IMO, the fact that all CPU's must be validated to function properly even in "permanent" turbo mode will be a big gain for overclockers because they will be able to eat up that easy, pre-validated margin.

Oh now you are just needlessly arousing me...stop with the sweet talk already!

I'm ready for some Bloomfield action! Bring on the chips!

just read something interesting while researching santa rosa platform: this platform ALREADY bumps up the cpu clock during single-threaded apps but makes sure to stay within the stated tdp at all times: ie, my T7250 can turn on the "turbo" button right now in a very intense single-threaded app as long as it doesn't exceed the stated 35w tdp. they've had santa rosa out for 11 mos now, so doing this on a nehalem destop/server will be a no-brainer imho.

 

[virtualrain]

Originally posted by: bryanW1995

Originally posted by: Idontcare

Originally posted by: dmens
IMO, the fact that all CPU's must be validated to function properly even in "permanent" turbo mode will be a big gain for overclockers because they will be able to eat up that easy, pre-validated margin.

Oh now you are just needlessly arousing me...stop with the sweet talk already!

I'm ready for some Bloomfield action! Bring on the chips!

just read something interesting while researching santa rosa platform: this platform ALREADY bumps up the cpu clock during single-threaded apps but makes sure to stay within the stated tdp at all times: ie, my T7250 can turn on the "turbo" button right now in a very intense single-threaded app as long as it doesn't exceed the stated 35w tdp. they've had santa rosa out for 11 mos now, so doing this on a nehalem destop/server will be a no-brainer imho.

I recently came across this as well. Apparently Santa Rosa will only increase the active core multi by x1... while the data I came across seems to imply the possibility of up to a x3 multi change... (see slide here)

 

[Idontcare]

Originally posted by: bryanW1995

Originally posted by: Idontcare

Originally posted by: dmens
IMO, the fact that all CPU's must be validated to function properly even in "permanent" turbo mode will be a big gain for overclockers because they will be able to eat up that easy, pre-validated margin.

Oh now you are just needlessly arousing me...stop with the sweet talk already!

I'm ready for some Bloomfield action! Bring on the chips!

just read something interesting while researching santa rosa platform: this platform ALREADY bumps up the cpu clock during single-threaded apps but makes sure to stay within the stated tdp at all times: ie, my T7250 can turn on the "turbo" button right now in a very intense single-threaded app as long as it doesn't exceed the stated 35w tdp. they've had santa rosa out for 11 mos now, so doing this on a nehalem destop/server will be a no-brainer imho.

:shocked: You have GOT to do me a HUGE favor! Please please please.

Start a single-threaded app, F@H or something you know is single-threaded but will fully peg a core to 100% utilization.

Then open task manager and confirm for me whether or not the thread (and CPU utilization) stays on one core or whether it migrates to the other cores and task manager reports all the cores are roughly equally loaded.

And confirm that the "turbo" is happening on one of the cores (not sure how you do this, I guess CPU-Z and change the core using that pulldown tab?)

Pretty please

 

[bryanW1995]

ok. I'm headed to work right now, so I'll try it this afternoon.

 

[bryanW1995]

ok, I did it and I know the system works b/c I physically saw it jump to 11x, but it was a VERY brief jump. I'm running seti on only 1 core (just took it down from both cores to one only). system immediately went down to 6x (eist is enabled), up to x11, then back down to x10. still at x10 b/c even though I'm at 50% cpu usage I don't know how to set affinity on it. I'd rather not install a huge program like f@h if I can just do it with orthos or something, however, b/c I want to see this thing at 11x for long enough period of time to at least get you a screenshot!

 

[aigomorla]

Originally posted by: bryanW1995
ok, I did it and I know the system works b/c I physically saw it jump to 11x, but it was a VERY brief jump. I'm running seti on only 1 core (just took it down from both cores to one only). system immediately went down to 6x (eist is enabled), up to x11, then back down to x10. still at x10 b/c even though I'm at 50% cpu usage I don't know how to set affinity on it. I'd rather not install a huge program like f@h if I can just do it with orthos or something, however, b/c I want to see this thing at 11x for long enough period of time to at least get you a screenshot!

yeah that 11x multi is confusing when the max multi is 10x.

makes me think why no one cant think of a hack to trick the fsb to unlock your cpu.

Kinda like a reverse speedstep thing if you get my drift. Instead of clocking from 10x -> 6x how would you like one that goes 10x -> 15x while holding your fsb constant.

 

[bryanW1995]

well, my cpu fan gets going pretty fast when I run seti full blast as it is...I probably wouldn't want a faster cpu unless it was a 45nm. I did see that the 9300 is only $319 at newegg right now, however. Hopefully by the time I decide to upgrade this I'll be able to get a 3.0ghz penryn for less than $200.

 

[Idontcare]

Originally posted by: bryanW1995
ok, I did it and I know the system works b/c I physically saw it jump to 11x, but it was a VERY brief jump. I'm running seti on only 1 core (just took it down from both cores to one only). system immediately went down to 6x (eist is enabled), up to x11, then back down to x10. still at x10 b/c even though I'm at 50% cpu usage I don't know how to set affinity on it. I'd rather not install a huge program like f@h if I can just do it with orthos or something, however, b/c I want to see this thing at 11x for long enough period of time to at least get you a screenshot!

Cool. No need for F@H, I was just giving an example of a known single-threaded program.

The relevant info is what you stated and I bolded above.

This (thread migration from core to core) is the problem with the "turbo" feature. Thread migration breaks the turbo feature and I don't see Nehalem being a special case where this doesn't happen.

The reason your 11x multi dissappears is because the OS allows the thread to migrate, and as soon as it migrates off the initial core onto a neighboring core then the "turbo" feature disables itself as the OS is asking the BIOS to allow all the cores to run at full speed so that they can entertain your single-threaded app 50% of the time.

Yes you can force thread affinity in task manager but this defeats the point of the exercise I wanted you to do...the exercise being to determine whether turbo function was actually going to work when you add microsoft's OS thread management into the fray.

The only value of an automatic turbo feature is if it actually is enabled and utilized seamlessly and transparently to the user...thread migration will forever plague this feature until the OS becomes "affinity locking" savy.

Bummer, major bummer. But it's not like this is the first time Intel got all the way to implementing a seemingly cool feature only to find out it doesn't help worth a damn. Intel Santa Rosa Preview: Centrino V Evolves - Turbo Memory

And thank you very very much for running this test. :thumbsup:

I wish the results turned out differently but at least I know not to be looking forward to a functional turbo feature with too much excitement now.

 

[bryanW1995]

you're welcome, and thanks for the info on locking thread affinity btw. I was curious so I went ahead and ran a single thread in seti with thread affinity locked. I wasn't staring constantly at cpu-z, but I don't believe that it even kicked up to 11x now! I verified in task manager that cpu-0 was at 100% and cpu-1 was at 0. Well cpu-1 was never completely at zero, thanks to all the crap that dell and m$ have conspired to have running in the background on this poor computer (/rant), but it was VERY close to 0%.

One thing to keep in mind is that if nehalem implements this feature and it really is a 3x multi (how will that work with no fsb btw) then there will probably be many more single-threaded apps that are written with thread affinity. It's like all the twimtbp games that nvidia has, they don't necessarily have the best graphics horsepower but the games are (theoretically) optimized for nvidia so they run better on them. If amd somehow pulls a rabbit out of their hat with bulldozer and gets it out relatively close to nehalem's release, things like this turbo feature could end up keeping intel on top.

 

[Idontcare]

Originally posted by: bryanW1995
One thing to keep in mind is that if nehalem implements this feature and it really is a 3x multi (how will that work with no fsb btw) then there will probably be many more single-threaded apps that are written with thread affinity.

That is the software way of doing it...recompiling all the single-threaded programs out there so they are affinity self-aware and they lock themselves to the "turbo core".

As this will never happen in reality, safe for a few super popular programs, I was really hoping Intel was going to figure out a way to make it happen it hardware...i.e. have the CPU manage its own core loadings and effectively lock a single-thread locally when it detects the loadings aren't high on the other cores (i.e. background threads) while engaging the turbo feature.

Maybe they did it for Nehalem but not Santa Rosa...I'm not holding my breath though.

 

[IntelUser2000]

Intel had this dynamic overclocking feature ever since Santa Rosa, with the Merom cores. Penryn mobiles have it, and now Nehalem will have it. I think this is just them trying to give artificial advantage in mobiles over desktops to close the gap between them. Like how even the value version of the mobile IGP has hardware VS, but on desktops only the top version has them.

Anandtech had a benchmark with the feature. Search for it. I doubt they will change much with Nehalem.

About transistor count of Nehalem: Cache takes majority of transistor space. Reducing the total cache size by 3MB almost guarantees you'll have less transistors than the older cores with more cache but simpler cores.

Almost all of the Nehalem variants will have IMC very close to the actual CPU core, except for maybe the really cheap Celeron versions. The versions with integrated graphics has the GPU and the memory controller on one die and CPU on another connected by quickpath using MCM. Not integrated as you can get, but it'll be far closer.

 

[dmens]

Originally posted by: Idontcare
The only value of an automatic turbo feature is if it actually is enabled and utilized seamlessly and transparently to the user...thread migration will forever plague this feature until the OS becomes "affinity locking" savy.

Alternatively, the CPU can control its power with enough granularity such that context switching no longer becomes an issue.

 

[virtualrain]

Originally posted by: bryanW1995
One thing to keep in mind is that if nehalem implements this feature and it really is a 3x multi (how will that work with no fsb btw)

Nehalem will most likely implement a clocking scheme similar to Phenom with a reference clock (somewhere around 200MHz) and then a multi for the CPU, the QuickPath Interconnect, the IMC, and then a divider for the memory frequency. It's even possible that each core might have it's own multi.

 

[Idontcare]

Originally posted by: dmens

Originally posted by: Idontcare
The only value of an automatic turbo feature is if it actually is enabled and utilized seamlessly and transparently to the user...thread migration will forever plague this feature until the OS becomes "affinity locking" savy.

Alternatively, the CPU can control its power with enough granularity such that context switching no longer becomes an issue.

You raise a good point...if the time required for the CPU to switch power states on any given core is appreciably less than the average resident time the thread keeps itself local then you'd be good to go.

It seems like this is something that Intel (or Microsoft) could make a little program for you that would run in windows (and a linux version too would be nice) where the user would "register" their programs which they think are candidates for "turbo" mode (not all users will correctly determine if their programs are single-threaded, so the "program" ought to do this assessment for them in situ) and then the program would know which core is the designated "turbo core" and appropriately locks the affinity when the application is launched.

 

[Idontcare]

Originally posted by: bryanW1995
I'd bet that oc'ing on the nehalem will be more complicated than lga 775's...probably more like on amd's right now.

Here's a quoted post from an Intel employee posting (just his personal opinion, not official Intel speak I'm sure) in the XS forums:

Originally posted by: Blauhung
The Lynnfield and Havendale varriants on the nehalem core will most likely be locked to JDEC established speeds set through SPD settings, so there might not be support for some of the higher speeds that aren't spec'd out yet.

Bloomfield and Gainstwon on the other hand have a scalable NB that will most likely be setting the base clock frequency that CPU and memory frequency. Just like now there will be selectable multipliers as well. Really the high end desktop and server platforms should be nice and configurable on the memory front.

So in summary, you should be fine with what you have, just don't expect to be able to tweak anything if you end up with the mainstream platform.

http://www.xtremesystems.org/f...=2961711&postcount=140

Food for thought, particularly that last sentence.