Fiery

Then please try to go to the Display / GPU page, and select all video adapters you have, one by one. Let me know if it triggers the same desktop refresh or not. We need to narrow this down to a specific part of the hardware monitoring module of AIDA64 BTW, what kind of Windows do you have installed? Win7? 32-bit or 64-bit?

I'm pretty sure the HFM issue is not related to AIDA64 at all, so I'm afraid I can't help you about that. AIDA64 does change power management settings before running benchmarks, but it changes them in a way to squeeze out the most performance from the CPU. It definitely doesn't alter power settings in a way to make the CPU run at LFM. As for the 50C vs. 60C issue, you can lower TJMax temperature (in AIDA64 / main menu / File / Preferences / Hardware Monitoring) if you're adament that Everest was more accurate on core temperature measurement.

1) The access violation error may be a bug in AIDA64, a bug in Intel RAID drivers, or an issue where AIDA64 communicates with the Intel RAID drivers. We'll try to reproduce this issue in our labs, and then fix it up if possible. I'll drop a message in this topic once we have an update to this matter. Until then, you can simply ignore the access violation issues, since I'm confident it doesn't mean there's a stability issue with your system. However, in case while running the Stability Test a BSoD occurs, or the system locks up, then there's a stability issue 2) The warning about EC is simply due to AIDA64 communicating with the EC chip (Embedded Controller) of your motherboard. We've done some improvements in the past few months to try eliminating those warnings by rewriting the EC communication layer of AIDA64. The new layer works much better, but in rare cases it may still trigger something in Windows kernel that causes the kernel to place such warnings in the Event Logs. It's not a problem at all, it doesn't affect system stability or system performance at all, so you can simply ignore those warnings. The MSI motherboards don't have an EC chip, hence AIDA64 doesn't use EC communications on them. Regards, Fiery

Please try to disable Low-level SMART operations in AIDA64 / main menu / File / Preferences / Stability, and restart AIDA64. Let me know if it makes the issue go away, or it still persists. Thanks, Fiery

Intel core temperature diodes are well known to have accuracy issues. Accuracy is only guaranteed close to TJMax. You don't need to worry too much about temperatures as long as your processor is not throttling under heavy load.

1) Please copy-paste the full content of the Computer / Sensor page of AIDA64 into this topic. 2) Then right-click on the bottom status bar of AIDA64 main window --> Disk Debug --> SMART Dump. Copy-paste the full results into this topic. Thanks, Fiery

On most motherboards (including most Asus boards) the motherboard temperature equals to the internal temperature reading of the sensor chip that is integrated on the motherboard PCB. On your motherboard however the sensor chip reads the motherboard temperature from a special register that is only used on a handful of Asus motherboards to measure temperature. So we simply had to modify the motherboard-specific sensor code for your motherboard to switch from the usual register to the special register

Thank you for the data. Please upgrade to the latest beta version of AIDA64 Extreme Edition available at: http://www.aida64.com/downloads/aida64extremebuild1734k9g4vtlhfszip After upgrading to this new version, make sure to restart Windows to finalize the upgrade. Let me know if it helps. Thanks, 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