Nehalem Clocks and Turbo Mode

[virtualrain]

I recently blogged this on Nehalem News and I'm interested in your thoughts...

A big question on everyone's mind is what CPU frequency will intial Nehalem parts be clocked at and what overclocking head room might exist?

Although a demo machine was recently reported to be running Nehalem at 3.2GHz, we can't be positive based on the evidence provided that this early sample was, in fact, running at that speed. However, it's not unreasonable for Bloomfield to launch at 3GHz speeds given that Penryn's highest binned parts are shipping at 3.2GHz. This is supported, in part, by the fact that Nehalem's 731 million transistors compares favorably to Penryn's 820 million (both at 45nm).

It seems plausible that Nehalem should theoretically clock just as well as Penryn at the same Thermal Design Power (TDP) with the same cooling solution. The big unknown is what effect the onboard Memory Controller Hub (MCH) will have on clock speed limitations.

Another intersting aspect to Nehalem is the reports of a "Turbo Mode". While published details are hard to come by, this dynamic core clocking capability is illustrated in the slide below (courtesy of HKEPC). It appears to be an extension of the Performance States of the Adavanced Configuration and Power Interface (ACPI) specification also know as SpeedStep technology (P-States). It suggests that when load allows one or more cores to be throttled down into a low frequency mode (LFM) the remaining active loaded cores can actually be overclocked to higher than default clock frequencies as long as the default TDP is not exceeded.

View Image

While this is an exciting development, unfortunately it raises more questions than it answers.... for example, it's not clear if this feature will work with overclocked chips or only those running at default clocks and multipliers. It's also not clear what events or conditions trigger the LFM for the unutilized cores and similarly what events or conditions trigger the overclocked P-states of the active cores. Finally, there's no insight into how much control the BIOS, OS, or end-user will have over this capability.

We can only hope that Nehalem's Turbo Mode follows the current SpeedStep implementation which can be managed at both the BIOS and/or Operating System level to allow modifying the multiplier in response to CPU loads. That is, if one overclocks their reference clock from default, this feature will ideally manage core clocks by adjusting the multi's up or down as load dictates thus allowing overclockers to benefit from this feature as much as factory clocked systems.

If this feature does support overclocking, it will add another dimension to stability testing as a stable operating point for all 4 cores will also have to consider the "Turbo Mode" state.

Needless to say, the benefits of this kind of dynamic overclocking with balanced performance on multiple cores for multi-threaded apps while also offering maximum clock speed on single-threaded programs, all with the same cooling solution, effectively ensures one can "have their cake and eat it too"!

I'm interested in your thoughts on this.

Cheers,
-Chris.

 

[Idontcare]

Personally I feel this kind of blog self-promotion is inappropriate here.

If you want to post a thread in the AT forums on your musings and opinions then post a thread...not a link with snippets to some other website which contains your musings and opinions.

If you want post a thread in the AT forums with your musings and opinions regarding the contents of an article located on a valid news (TGDaily, etc) then by all means post a link.

But don't come here (and god only knows how many other tech forums you are trawling for hits from) to try and drum up the clicky-cliks in hopes of someday generating enough web-traffic that you can be the next TGDaily.

Do it the honest way, stop the shameless blog self-promotion. Please.

 

[TonyB]

lol

 

[bryanW1995]

I don't think that it's inappropriate for him to post some thoughts on nehalem in a cpus/overclocking forum at a tech web site. A bunch of us are starving for nehalem info as it is, and chris' site seems to offer some good info on what we'll see going forward. And it's unlikely that a blog site that will be useless in 12-18 mos will turn into another AT or Tom's regardless of how many topics like this he posts around the web.

 

[Hulk]

I don't see how anyone can guess at how well Nehalem will clock at 45nm or any other process size since as we all know clock speed is dependent on architecture AND process. We would hope that Nehalem will have the "guts" to clock at least as high as Penryn at the same process but that's an easy guess since we're assuming Intel won't move backwards but will build on Penryn. And since Penryn/Conroe does very well IPC-wise I wouldn't expect a major increase there with a decrease in clockspeed like we saw when moving from P4 to Conroe. But as I said this is all guesswork.

As for shutting down cores and increasing active core speeds to suit the threading of the application. I think that's a good idea. Unless of course programmers decide to not multithread efficiently because they know they can get nearly the same performance going single thread since the processor will crank up the clock of the core running the thread.

 

[aigomorla]

ROFL..

welcome back to the 8086 and 286 genres.

Dayam i miss that little turbo button.

 

[Phynaz]

This is spam.

 

[Foxery]

"Turbo Mode" back in 386 days meant that you could turn it off and slow down the CPU when you needed to simulate 286 speeds for an old application. Marketing garbage at best.

However, if they decide to dynamically shut down cores in order to ramp up the speed+heat of other cores, that would be neat. I'm not sure I believe that such a feature will show up right away, but it's an interesting concept for the future.

 

[aigomorla]

Just want to speak up.

His blog has no advertisements, no sponsor ads.

Its very unbaised, and he has appropreate links.

True he should link the original source, however i dont see anything wrong with his blog for a neha information collection.


Considering that 75% of the internet users are too lazy to do a google hit when needed, i think his blog is a very nice collection.

 

[Rubycon]

Originally posted by: aigomorla
ROFL..

welcome back to the 8086 and 286 genres.

Dayam i miss that little turbo button.

Better make it a DPDT switch so you can engage the high speed line on your water pump! :laugh:

 

[aigomorla]

Originally posted by: Rubycon

Originally posted by: aigomorla
ROFL..

welcome back to the 8086 and 286 genres.

Dayam i miss that little turbo button.

Better make it a DPDT switch so you can engage the high speed line on your water pump! :laugh:

oh yeah i need a 1gpm mode for idle, and a 3gpm mode for turbo!

Hell might as well modify the pump so its pwm style along with it!

 

[Idontcare]

Originally posted by: aigomorla
Just want to speak up.

His blog has no advertisements, no sponsor ads.
Its very unbaised, and he has appropreate links.

True he should link the original source, however i dont see anything wrong with his blog for a neha information collection.


Considering that 75% of the internet users are too lazy to do a google hit when needed, i think his blog is a very nice collection.

And what manner of fashion would you expect an Intel viral ad campaign for Nehalem to manifest?

I'm not the against the existance of blogs, pro Nehalem, viral, or otherwise. Nor am I against posting a link in your sig to your unsubstantiated not-a-viral-campaign website...but I am against the idea of creating a thread specifically to goad Anandtech forum members into clicking on your link just to see the rest of the story.

The OP could have easily cut-and-pasted his relevant blog content into this thread and asked the same question...I'd have no issue with that. (could still be viral, spam as Phynaz put it, but you can only attempt to insulate the forums to a point)

Edit: I see the OP has been edited to include what appears to be the relevant material for the discussion. My objection has been nullified. Thanks OP.

 

[Rubycon]

Originally posted by: aigomorla

oh yeah i need a 1gpm mode for idle, and a 3gpm mode for turbo!

Hell might as well modify the pump so its pwm style along with it!

Put in the Flotronic - even the smallest one will do 100's of PC's AND still have enough capacity to cool a 2,000 m³ domicile at 25°C wetbulb! :laugh: RRPID rotary ball valves on the loops to maintain tight temps - glycol target temp is 5°C so PLENTY of coolth for toasty 45nm quads eating EMF at 1.5 volts.

 

[v8envy]

And this is why I fear to truly 'get into' water cooling. After a while you people must look at a toilet and go "You know. I could make that flow better. And quieter."

On topic: if this is a design feature I'm all for it. Upgrade your cooling to get an automagic supported OC, possibly on all cores? Yes please!

 

[Idontcare]

Originally posted by: virtualrain
However, it's not unreasonable for Bloomfield to launch at 3GHz speeds given that Penryn's highest binned parts are shipping at 3.2GHz. This is supported, in part, by the fact that Nehalem's 731 million transistors compares favorably to Penryn's 820 million (both at 45nm).

Seems very plausible considering the 3.2GHz speed-bin parts do not represent the top speed-bin that Intel could create a SKU for. We've seen 3.6-3.8GHz on air without much fuss.

I agree with the train of thought, but I don't think you can rely on Yorkfield's top speedbin as being an indicator of the quality of the underlying process technology (other than it is obviously not a problem).

Originally posted by: virtualrain
It seems plausible that Nehalem should theoretically clock just as well as Penryn at the same Thermal Design Power (TDP) with the same cooling solution. The big unknown is what effect the onboard Memory Controller Hub (MCH) will have on clock speed limitations.

A larger issue, I expect, is the yield. The larger monolithic die with less surface area comprised of cache compared to Yorkfield means flat-out that the yields will be lower.

The speedbin distributions will likely be similiar between Nehalem and Yorkfields, but the quantity of Nehalems at those speed bins will be handidly supressed thanks to the defect density of the fab.

This raises costs, which goes against the hopes of selling the newest gen CPU's at higher gross margins than the prior gen CPU's...and what rationally operated company is going to lower GM's if they don't have to.

So I expect similiar clocked Nehalems to Yorkfields...but the SKU's will be at least 20% higher in price (my expectation) to even out the ~20% lower yields (my expectation) of Nehalem over Yorkfield.

Originally posted by: virtualrain
Another intersting aspect to Nehalem is the reports of a "Turbo Mode". While published details are hard to come by, this dynamic core clocking capability is illustrated in the slide below (courtesy of HKEPC). It appears to be an extension of the Performance States of the Adavanced Configuration and Power Interface (ACPI) specification also know as SpeedStep technology (P-States). It suggests that when load allows one or more cores to be throttled down into a low frequency mode (LFM) the remaining active loaded cores can actually be overclocked to higher than default clock frequencies as long as the default TDP is not exceeded.

View Image

While this is an exciting development, unfortunately it raises more questions than it answers.... for example, it's not clear if this feature will work with overclocked chips or only those running at default clocks and multipliers. It's also not clear what events or conditions trigger the LFM for the unutilized cores and similarly what events or conditions trigger the overclocked P-states of the active cores. Finally, there's no insight into how much control the BIOS, OS, or end-user will have over this capability.

We can only hope that Nehalem's Turbo Mode follows the current SpeedStep implementation which can be managed at both the BIOS and/or Operating System level to allow modifying the multiplier in response to CPU loads. That is, if one overclocks their reference clock from default, this feature will ideally manage core clocks by adjusting the multi's up or down as load dictates thus allowing overclockers to benefit from this feature as much as factory clocked systems.

If this feature does support overclocking, it will add another dimension to stability testing as a stable operating point for all 4 cores will also have to consider the "Turbo Mode" state.

Needless to say, the benefits of this kind of dynamic overclocking with balanced performance on multiple cores for multi-threaded apps while also offering maximum clock speed on single-threaded programs, all with the same cooling solution, effectively ensures one can "have their cake and eat it too"!

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.

 

[Foxery]

Whoops, I read this more carefully now. Sounds like a really cool feature - essentially gives you a speed boost on single-threaded apps when the extra cores are going to waste. It also creates a new motivation for us as consumers to buy products with more cores, as opposed to the current daily thread about, "well, I can overclock a dual core higher for my gaming needs, so a quad is pointless."

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.

I hope that's not true. It's a great performance boosting feature, and I could have sworn that these companies were paying more attention to electrical consumption in server and desktop products lately... Companies with server rooms would love the idea that each machine could dynamically shut down inactive CPUs to save power+heat.

 

[aigomorla]

Originally posted by: Idontcare

And what manner of fashion would you expect an Intel viral ad campaign for Nehalem to manifest?

I'm not the against the existance of blogs, pro Nehalem, viral, or otherwise. Nor am I against posting a link in your sig to your unsubstantiated not-a-viral-campaign website...but I am against the idea of creating a thread specifically to goad Anandtech forum members into clicking on your link just to see the rest of the story.

The OP could have easily cut-and-pasted his relevant blog content into this thread and asked the same question...I'd have no issue with that. (could still be viral, spam as Phynaz put it, but you can only attempt to insulate the forums to a point)

Ahhhhh i see your point.

However thats why theres people like you around

IDC if you feel his information is flawed let him know. But when i was reading that site, not once has it lead me to feel as he was a viral agent.


Just my opinion.

But i do see your point.

 

[virtualrain]

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.

That's my fear as well. I think it would offer a lot of value on the desktop... just like SpeedStep does in offering a blend of silence and performance for 24/7 operation. I know a lot of overclockers that use SpeedStep on their overclocked rigs to great effect. For example if you have a stable OC at 400x9 (3.6GHz) you can enable SpeedStep and when idle or surfing the web your CPU will run at 400x6 (2.4GHz) but immediately ramp up as soon as any core is under load (watching a video, gaming, etc.)

I think the intent behind this Turbo Mode is to extend this SpeedStep so that it doesn't just lower the multi when idle, but can also increase the multi when a couple of cores can be disabled creating extra TDP headroom. Thus, following the example above, you may find a couple of cores on your CPU able to run at 400x11 (4.4GHz) in a game that only uses one or two cores and the others are effective shut down (LFM).

ps. I'm just a PC enthusiast with a passion for Nehalem and a desire to share what I've learned/compiled with others in the hopes they might benefit from it... which I think is one of the greatest features of the www. I just don't know how to let people know about the stuff on my site with out posting it somewhere. Sorry if I came across as a self-promoter or viral marketer. I wish I was getting paid for this!

 

[Idontcare]

Originally posted by: virtualrain

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.

That's my fear as well. I think it would offer a lot of value on the desktop... just like SpeedStep does in offering a blend of silence and performance for 24/7 operation. I know a lot of overclockers that use SpeedStep on their overclocked rigs to great effect. For example if you have a stable OC at 400x9 (3.6GHz) you can enable SpeedStep and when idle or surfing the web your CPU will run at 400x6 (2.4GHz) but immediately ramp up as soon as any core is under load (watching a video, gaming, etc.)

I think the intent behind this Turbo Mode is to extend this SpeedStep so that it doesn't just lower the multi when idle, but can also increase the multi when a couple of cores can be disabled creating extra TDP headroom. Thus, following the example above, you may find a couple of cores on your CPU able to run at 400x11 (4.4GHz) in a game that only uses one or two cores and the others are effective shut down (LFM).

I don't recall the specific timeline but I do remember it took Intel many CPU generations to move EIST/Speedstep (whatever was the very first gen) from their laptop SKU's to their dekstop SKU's.

There was never really any reason not to have it in their desktop parts all along except that it required extra test time to validate the chips were functional for EIST/Speedstep and test time costs money (let alone the small percentage of chips you'd be throwing away for not passing the test).

What I like about the prospects of heterogenous compute nodes is that it is much more efficient at handling multi-threaded code in an Amdahl scaling world. All parallel code will have it's portions of serial code, and the serial code can only be sped up by making the core it is running on become faster.

Personally I wouldn't mind if my quad-core systems came with one core permanently clocked a bin or two higher than the remaining three cores (or seven cores if we are talking Nehalem EX)...provided the OS were capable of ensuring the "master" core for a multi-threaded program stayed resident on the higher clocked core.

In this situation the serial code processes faster, the distributable parallel code is parsed to slower but more numerous cores, and both multi-threaded and single-threaded applications get a speed-boots.

I'm keenly aware of this model as this is exactly the concept I developed for my Beowulf computing clusters in graduate school some 10 years ago. I had 12 nodes, eleven of which were 800MHz Athlons and one of which was a 1GHz Athlon.

The head node (also called the master node) was responsible for processing all serial code as well as managing the distribution and re-assembly of the distributed parallel code jobs. As such it made a rather sizable performance improvement to have the head-node operating 20% faster than the so-called slave nodes. (application dependent of course, my application was Gaussian98, a computational chemistry modeling application).

So I really hope as we keep pushing on making these multi-core chips have more and more cores that we also begin to skew them (for TDP reasons) into clockspeed heterogenous chips and make the OS aware of how to keep a master core the preferred core for multithreaded apps to operate single-threaded code paths on.

(AMD already has the software available to clock their cores independently on the Phenom, so you can have one core at 2.6Ghz and the remaining cores at 2.2GHz for example)

Originally posted by: virtualrain
ps. I'm just a PC enthusiast with a passion for Nehalem and a desire to share what I've learned/compiled with others in the hopes they might benefit from it... which I think is one of the greatest features of the www. I just don't know how to let people know about the stuff on my site with out posting it somewhere. Sorry if I came across as a self-promoter or viral marketer. I wish I was getting paid for this!

Forget about it, had you turned out to be what I was afraid you might be then you would have reacted completely differently to my posts above. That you handled yourself with the accomodating civility that you have is all the proof I need to see you are value-add here. Your enthusiasm is to be applauded, I applaud it and thank you for sharing your thoughts with us all here.

 

[bryanW1995]

Originally posted by: Rubycon

Originally posted by: aigomorla

oh yeah i need a 1gpm mode for idle, and a 3gpm mode for turbo!

Hell might as well modify the pump so its pwm style along with it!

Put in the Flotronic - even the smallest one will do 100's of PC's AND still have enough capacity to cool a 2,000 m³ domicile at 25°C wetbulb! :laugh: RRPID rotary ball valves on the loops to maintain tight temps - glycol target temp is 5°C so PLENTY of coolth for toasty 45nm quads eating EMF at 1.5 volts.

:heart: rubycon, you had me at domicle... Seriously, I thought that I was difficult to understand some times, but I often think you're speaking a whole 'nother language.

 

[bryanW1995]

Originally posted by: virtualrain
It seems plausible that Nehalem should theoretically clock just as well as Penryn at the same Thermal Design Power (TDP) with the same cooling solution. The big unknown is what effect the onboard Memory Controller Hub (MCH) will have on clock speed limitations.

A larger issue, I expect, is the yield. The larger monolithic die with less surface area comprised of cache compared to Yorkfield means flat-out that the yields will be lower.

The speedbin distributions will likely be similiar between Nehalem and Yorkfields, but the quantity of Nehalems at those speed bins will be handidly supressed thanks to the defect density of the fab.

This raises costs, which goes against the hopes of selling the newest gen CPU's at higher gross margins than the prior gen CPU's...and what rationally operated company is going to lower GM's if they don't have to.

So I expect similiar clocked Nehalems to Yorkfields...but the SKU's will be at least 20% higher in price (my expectation) to even out the ~20% lower yields (my expectation) of Nehalem over Yorkfield.

I think that you're being very generous witht he 20% lower yield and 20% higher price expectations. Especially with the lack of competition from anybody other than themselves, I would not be surprised at all to see a 50% + price bump for the same clocks, in fact, it might even start out at 50% + price bump for the same "performance level". Wouldn't it be cute to see intel go to a PL rating for their chips so that they could kick their own a$$es from the previous year??

 

[dmens]

Originally posted by: virtualrain
I'm interested in your thoughts on this.

Cheers,
-Chris.

AFAIK, dynamic power management is optional. I have no idea how many options will be user-controllable. But overclockers should turn it off to simplify matters.

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.

 

[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?

 

[Viditor]

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?

Because they won't all have IMC...at least not the first desktops.

Edit: I don't think most realise yet that Nehalem is going to have a LOT of variants!
If you like the S939 socket change from AMD, then the sockets for this next Intel transition are going to be a veritable Hootenanny for you...

If I am not mistaken, Intel is going to be selling no less than 4 different sockets at the same time (though some will be EOL fairly soon).

 

[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.