Fiery

We've checked it again. Here's the info coming from ASRock's own software, from their XML settings file applying to your motherboard: <Fan Enable="1"> <Item Index="0" Name="CPU_TEMP" Enable="1" Control="Temperature">CPU Temperature</Item> <Item Index="1" Name="MB_TEMP" Enable="1" Control="Temperature">M/B Temperature</Item> <Item Index="2" Name="FAN2" Enable="1" Control="FanReading">CPU Fan1 Speed</Item> <Item Index="3" Name="FAN6" Enable="1" Control="FanReading">CPU Fan2 Speed</Item> <Item Index="4" Name="FAN1" Enable="1" Control="FanReading">Chassis Fan1 Speed</Item> <Item Index="5" Name="FAN4" Enable="1" Control="FanReading">Chassis Fan2 Speed</Item> <Item Index="6" Name="FAN5" Enable="1" Control="FanReading">Chassis Fan3 Speed</Item> <Item Index="7" Name="FAN3" Enable="1" Control="FanReading">Power Fan Speed</Item> </Fan> <FanReading Enable="1"> <Item Name="FAN1" Bank="6" HighReg="0x56" LowReg="0x57">SYSFANIN</Item> <Item Name="FAN2" Bank="6" HighReg="0x58" LowReg="0x59" SwitchInterface="SIO_GPIO" SwitchControl="GPIO16=Low, GPIO10=High">CPUFANIN</Item> <Item Name="FAN3" Bank="6" HighReg="0x5A" LowReg="0x5B">AUXFANIN</Item> <Item Name="FAN4" Bank="6" HighReg="0x5C" LowReg="0x5D">AUXFANIN0</Item> <Item Name="FAN5" Bank="6" HighReg="0x5E" LowReg="0x5F">AUXFANIN1</Item> <Item Name="FAN6" Bank="6" HighReg="0x58" LowReg="0x59" SwitchInterface="SIO_GPIO" SwitchControl="GPIO16=High, GPIO10=Low">CPUFANIN2</Item> </FanReading> I've highlighted the fan readings in question. As you can see, they're both connected to the same 16-bit register (reg0x58/0x59), and they are muxed using a GPIO-based mux switch (GPIO16). So reading both fan speeds is only possible if you switch the mux. But the mux ASRock uses is quite slow and tough to handle from 3rd party software We've made test runs, but then gave up, because we couldn't handle the mux in a way to assure the fan readings are always coming from the fan header we select using the mux.

I'd rather not talk about any time frames, since currently we're simply swamped with ongoing projects We're working on OpenCL GPGPU Stress Test, new memory benchmarks, revamping existing CPU benchmarks, implementing Intel Ivy Bridge optimizations, ACPI 5.0, OpenCL 1.2, etc. etc. A lot of stuff, but we'll get to SensorPanel as well, and add some more juice to make it a bit fancier than it currently is.

AFAIK on your motherboard CPU Fan1 and CPU Fan2 are muxed on the same sensor chip fan speed register. The default state of the mux is to show the readings for CPU Fan1. Hence you need to connect the fan to CPU Fan1 header to let AIDA64 measure its fan speed

Every burn tests and stress tests use different patterns, different approach to put the system under heavy load, and try revealing any stability issues. AIDA64 System Stability Test is probably the most up-to-date of all, since we follow technology evolution on almost a daily basis. It already utilizes such cutting-edge techniques like AVX and XOP instructions, and generally capable of putting greater stress on the computer than other solutions. Hence -- to us -- it is no surprise AIDA64 System Stability Test is the one that can reveal the instability issue on your system BTW, the thermal stressing is also an area that we work on very hard, to make sure AIDA64 can heat the computer up very quickly and efficiently. If your computer can stand AIDA64 Stability Test both thermal-wise and stability-wise, then it is a well-built and well-tuned computer Regards, Fiery

"CPU" is the temperature measured by the sensor chip, while "CPU Package" is measured by the CPU itself using its on-die temperature diode. "CPU Package" should be the more accurate reading. "CPU IA Cores" and "CPU GT Cores" are also measured by the CPU itself, and show the temperature of the processing cores and the integrated GPU respectively.

That NB is the IMC (Integrated Memory Controller) component of your CPU. Hence its temperature is listed as CPU temperature on the Sensor page

AIDA64 needs to have administrator privileges to make its sensor layer work properly.

1) What motherboard you have? 2) Did you have an older version of AIDA64 installed on your system before installing the latest trial version? 3) Does your Windows user have administrator privileges? Thanks, Fiery

AFAIK Asus P8Z68 series motherboards are not capable of measuring their north bridge or south bridge temperature. In fact, Z68 chipset has no north bridge at all, but only a single south bridge chip (PCH). Regards, Fiery

We don't mean to produce such benchmarks that would be comparable to benchmark results obtained using other software. And our customers demand more real-life application benchmarks, instead of expanding the current set of synthetic benchmarks with even more synthetic ones

CPU ZLib and CPU Hash benchmarks produce a MegaByte/sec result, so it should be easy to interpret them The rest of the CPU benchmarks currently produce scores, which have no actual measurement unit. The unit could be "marks", just like with other benchmark software. Next year we'll revamp a selection of our existing AIDA64 benchmarks to produce more meaningful scores, e.g. MegaPixel/sec for CPU PhotoWorxx, and MegaByte/sec for CPU AES. The CPU Queen benchmark is a special one, since it solves a logical issue, hence there's no unit can be involved in making the score. We do not have a Dhrystone or Whetstone benchmark, and we do not plan to implement such benchmarks in AIDA64. Regards, Fiery

Yes, those L3 cache benchmark values look just fine for a Core i7-2600 CPU. The L3 cache is definitely operational in your CPU.

AIDA64 follows Intel's public DTS specifications, hence it should measure the right values if you have the right TJMax value configured. Automatic value means AIDA64 will take the TJMax value published by Intel, hence it should be the right one to use. The now discontinued Everest used different TJMax values, which may or may not be the right ones. But the right ones are now used by AIDA64. If you cannot get your notebook to operate at HFM at 100% load, then there's definitely something fishy about your system. You can check BIOS options, Power Management options (in Windows Control Panel), but if nothing helps, it may worth disabling or completely removing the manufacturer supplied power management software(s) you may have installed.

1) Low Level SMART operations has to be enabled to let AIDA64 read any temperatures from HDD and SSD drives. You can have that option enabled and RAID SMART support disabled if you want to prevent AIDA64 reading temperatures from RAID arrays. 2) Stability options and other Preferences options are described in the AIDA64 user's manual. Just press F1 while AIDA64 is open, or navigate to AIDA64 installation folder and open AIDA64.CHM file there. 3) Dell, Apple and Toshiba related sensor modules are not used on other manufacturer systems. You can disable the related Stability options if you want, but it won't make any difference Same goes for Koolance and T-Balancer, if you don't have such devices in your system, then you can disable those options.

You can try enabling the option called SMBus access through ACPI (Asus motherboards) in AIDA64 / main menu / File / Preferences / Stability. You need to restart AIDA64 after altering that option. Changing that may or may not help to fix that issue. AIDA64 implements industry standard mutexes to make sure its low-level hardware access features are synchronized with other monitoring software. Asus on the other hand refuses to implement those mutexes, hence their software (AI Suite) collides with other software, causing various anomalies Asus is the one who needs to improve their software, but as most big companies, they tend to avoid doing so, and simply state that "You shouldn't be running XXXX other software along with ours". Regards, Fiery

Yes, gauges and graphs are definitely on our list of improvements for "SensorPanel v2.0"

I guess it could be due to AIDA64 detecting SSD SMART attributes (including SSD temperature readings, if available) for your RAID array. Please try to increase or decrease the Disk temperature polling frequency value in AIDA64 / main menu / File / Preferences / Hardware Monitoring, and verify if the frequency of the blips follow the polling frequency change. Regards, Fiery

Please try to disable as many options on the Stability page in Preferences as possible. As a start, please disable the following options there: - RAID SMART support - SMBus access through ACPI - Apple SMC sensor support - Dell SMI sensor support - Koolance TMS-200 sensor support - T-Balancer sensor support - DIMM thermal sensor support - Toshiba TVALZ sensor support - Volterra VT11xx sensor support - GPU fan speed measurement After altering the Stability page options, make sure to restart AIDA64 to apply the changes. Please let me know if it helps. If not, then please try to disable one more option on the Stability page: - Fan divisor reconfiguration If none of those helps, let me know, and we'll create you a special AIDA64 build with enhanced debugging features to pinpoint the code segment where the AIDA64 sensor module halts on your system. Please use AIDA64 latest beta (Build 1720) for those tests. Thanks, Fiery

According to our own Sandy Bridge test runs -- albeit at slightly lower core clocks -- the mentioned AIDA64 benchmarks get memory bandwidth limited at high core clocks. You may want to use higher clocked DDR3 modules to squeeze out more performance from your system.

Do you use Turbo Boost? If yes, then can you please tell us all ratios you use? Max. Non-Turbo ratio, 1-core Turbo ratio, etc? Thanks, Fiery

Please right-click on the bottom status bar of AIDA64 main window --> Sensor Debug --> ISA Sensor Dump. Copy-paste the full results into this topic. That data will help us to investigate this issue. Thanks, Fiery

That's why I said "most chipsets". AIDA64 latest beta already includes reference results for Sandy Bridge-E with Quad Channel DDR3-1600, and Bulldozer with Dual Channel DDR3-1866. When a chipset or CPU doesn't support a memory grade officially, raising the memory ratio still makes it overclocking. If you raise the CPU core multiplier on an unlocked CPU (e.g. Core i7 Extreme Edition), it is still overclocking

It is due to a BIOS bug about building DMI information. Please check Q#10 at: http://www.aida64.co.../knowledge-base I'm pretty sure the L3 cache isn't actually disabled. You can check the L3 cache size on the Motherboard / CPU page in AIDA64. If it shows a non-zero value there, your L3 cache is enabled. You can also try to run the Cache & Memory Benchmark (AIDA64 / main menu / Tools / Cache & Memory Benchmark) -- you should see a L3 cache read score somewhere between the L2 cache score and the Memory score. Since the L3 cache is a slower buffer than the L2 cache, but faster than the system memory. And BTW, such DMI issues do not affect system performance or stability at all. Regards, Fiery

Different core temperature on Intel processors before the Core i3/i5/i7 era could be due to different TJMax value used. If you believe AIDA64 measures 10 Celsius more than what it should, then try to set a lower TJMax value in AIDA64 / main menu / File / Preferences / Hardware Monitoring.

1) Do you simply disconnect the drive without ejecting it from the System Tray icon? 2) Is it a USB, FireWire or eSATA drive? Thanks, Fiery