Gearslutz.com - View Single Post - Could this be why the Nehalem Mac's aren't faster?
View Single Post
Old 9th February 2010   #29
valis
Lives for gear
 
valis's Avatar
 
Joined: Apr 2006
Location: Northwest USA
Posts: 3,003

Quote:
Originally Posted by TAFKAT View Post
Hey Valis,

When disabling EIST in the BIOS on your SM board, is it actually disabling the C-states or simply not giving you the option to adjust the states. It will be interesting to see whether the C-States are still active- C1E would be the main focus.

Easy enough to check , set C1E on in BIOS, then disable the EIST and then check the clocking with CPU-Z , which communicates directly to the chip via CPUID. If the C1E states is still active it will report the CPU clocking down , even with EIST disabled

Windows simply reports the CPU's at full clock , when in fact they are being ramped down.

On the current single socket boards, C States and EIST are total separate in the BIOS, you can disable them individually without effecting the others.

If you disable EIST without disabling C1E and the other C States the hardware clocking control is still active. Turbo Boost is another variable as well, but that only clocks the CPU up, not down.

FWIW: The Tyan 5400 boards that were the same series as your system had access to C states, but didn't have an option to disable EIST , so every BIOS will be different. Same on single socket boards, except it was the opposite ,some have access only to EIST, not to C-States.

From what I have experienced its imperative to disable the C states on a workstation where possible. Some anomalies unrelated to clocking that I experience on my current X58 development system with the C states active range from high pitched whining from the VRM's to earthing artefacts in professional PCI/PCIe audio cards , to even stranger occurrences in OSX with mouse / GUI causing the VRM/earthing issues.

Disabling the C Halt and EIST and it all goes away.

The power management states and their associated anomalies are a constant enigma to me at times.
TAFKAT, my bios settings expose the following under the 'advanced processor features' section:
  • Thermal Management 2 (TM1/TM2/ETTM) as cpu throttling methods in overheat conditions
  • C1/C2 Enhanced mode (enabled/disabled)
  • Intel EIST Support (Disabled/GV1&GV3 Only/C States Only/Enabled)
  • C States Supported (C1/C1C2/C1C2C3/C1C2C3C4)
My understanding is that Thermal Management 2 (TM1/TM2/ETTM) sets the cpu throttling methods used in overheat conditions (ETTM applies TM1 methods even when TM2 has been active if TM2 alone doesn't reduce thermal conditions enough.)

When I read up on "C1/C2 Enhanced mode" it seemed to mean that EIST can use these states to reduce voltage as well as clock with the cpu in active mode (not just under halt/idle cpu conditions) and when "C States Only" was selected for EIST support voltage changes stopped. Intel's documenation seemed to say that when EIST is disabled but C1E is enabled, the processor will not change its clock speed and voltage when it is executing instructions no matter what the load (10% or a 100%.) It will change its frequency and voltage only when it starts sleeping (C1, C2 and etc.). Setting C-states only did indeed show this in cpu-z.

Now I realize that this is just what the BIOS exposed, so in reading Intel's documentation and various articles about EIST online it seemed to me that the register I referred to above is the mechanism used by both. However when the hardware performs control it isn't able to set as many values for the register, hence why non-EIST mode has fewer states overall and doesn't support some of the P-states. Again this was just my understanding, but my Core1 & Core2 era machines all reflect this in bios including single socket Supermicro & Intel boards. It's quite possible that this is again just a peculiarity of using workstation/server hardware only though (I know that a lot of overclocking boards are even more confusing as taking the board out of 'auto' modes can make the P-states very confusing since there is so much control over the voltages.)

And again, I don't have a nehelem-generation machine at the moment to investiagate the C1 Halt full core parking (core powered down) issues, but it does seem as if there's something afoot there. I've seen the C1E/Halt 'vrm noise' issue reported on quite a few different models of motherboards for x58 & 5500 series boards, so it was good that you mentioed that . I also keep mentioning that I've now seen several reports of high-usage RAID & bonded 10-gig ethernet i/o issues reported that seemed related to the amount of hardware interrupt calls generated by Nehelem cpu's under EIST & C1E alike. As a user of DSP cards and Asio/Core audio cards, seeing other high i/o situations that are being throttled by high interrupt calls from power saving features bothers me...I've dealt with PCI bandwidth & i/o issues too much over the years.

Quote:
Originally Posted by TAFKAT View Post
Sorry I didn't explain that too well, what I meant by flat out was only in reference to the clock speed being flat out , so at low to moderate load there would be a temp advantage , but not once the CPU clocks to full speed.

With the Cooling, system burn ins at build/development should be at 100% load for long periods to ensure the system will be capable of handling extreme work loads, so on 50-60% working environments, there is still plenty in the tank.

Of course that would be valid for professional workstations, but I doubt that would be a priority for more domestic usage, and thats were some users could get themselves into a trouble with cheaper alternatives.

I understood you and agree, I was just stating that many home users (who may read here) might fit the last category as well as those who have done burn-in on their systems (I always do before even bothering with OS isntall & system configuration.) Overall though I think that the core-clocking itself isn't probably a problem (it's been present in desktop PC's since the P3 and more active in even the netburst/P4 era than I think people realized.) The issue here is that Nehelem systems are showing a wide variety of issues (as mentioned above) and most seem related to core parking and/or the fine-grained nature of the multicore C1E/EIST in these latest generations of cpu's.
valis is offline   Reply With Quote