virtualrain
04-28-2008, 12:45 AM
I recently blogged the following article and I'm interested in your opinion...
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 (http://www.nehalemnews.com/2008/04/news-nehalem-pictured-running-at-32ghz.html), 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.
http://www.hkepc.com/database/images/2008010318075171704201286.jpg
(source: HKEPC (http://www.hkepc.com/?id=568&page=5&fs=idn#view))
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"!
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 (http://www.nehalemnews.com/2008/04/news-nehalem-pictured-running-at-32ghz.html), 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.
http://www.hkepc.com/database/images/2008010318075171704201286.jpg
(source: HKEPC (http://www.hkepc.com/?id=568&page=5&fs=idn#view))
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"!
Thoughts?