Fiery

Thank you. The issue is already fixed in the latest beta version of AIDA64 Extreme available at: http://www.aida64.com/downloads/latesta64xebeta Regards, Fiery

In case your display offers a standard DSub VGA connection, and you can connect it to your computer as a secondary monitor, then you could extend Windows Desktop to it, and use SensorPanel instead of the LCD module of AIDA64 to display various sensor readings.

Thank you for the feedback

I'm sorry, I've mixed up 3430 and 3431 The right one is the 3430 build.

The change we've introduced in Beta Build 3430 affects misc temperature ("Temperature #n") values. Previously, misc temperature values may overlap across sensor devices. So e.g. in your case, your motherboard sensor can measure 3 misc temperature values that AIDA64 calls Temperature #1 to #3 (it is labelled as "T_Sensor1" to "T_Sensor3" by Asus), but your Aquaero device can also measure a series of misc temperatures that AIDA64 called Temperature #1 .. #44. On previous builds Temperature #1 to #3 coming from Aquaero overlapped with Temperature #1 to #3 measured by your motherboard sensor, hence you lost 3 readings, the ones for the motherboard. Now AIDA64 handles those readings in a sequential manner, so all temperatures are kept and they will never overlap. This unfortunately has a side-effect on such mixed sensor configurations like yours, so it may require adjustments for LCD and SensorPanel layouts. We've delayed making this necessary change for that reason, but lately we've received many inquiries about overlapping readings, so it was now hard to avoid making that step. As for the missing temperatures, they should be there now. If they're not, then please copy-paste or attach an ISA Sensor Dump and an Embedded Controller Dump, and we'll check what's going on. Please make sure to use AIDA64 Build 3431 where we've fixed some issues over the 3430 build.

Thank you, we'll add the missing information in the next AIDA64 beta update due next week. Regards, Fiery

That's actually a much more complicated issue than the 2 lines of "if ... then" sequence you've mentioned. AIDA64 always tries to handle things automatically, so that the user wouldn't have to worry about every single bits of configuration. When you start AIDA64 without previously altering the Preferences settings, it will automatically tick (enable) a pre-defined list of sensor icons. Since those are a pre-defined list, the items on the list may or may not be supported by the current system. For example, it will enable CPU Fan, System Fan, Chipset Fan, Chassis Fan, etc. And since it's not possible to know which items do exist on the current system, AIDA64 automatically will hide the ones that provide an invalid reading, like 0 RPM, negative RPM or excessively high (unrealistic) RPM like 60000 RPM. That logic assures that only the actually valid items from the pre-defined list would appear automatically on the System Tray as sensor icons. And when I say "it will automatically tick" a certain list of sensor icons, it means it sets their SHOW property to 1 (enabled). It is the same property that you can alter by ticking the checkbox next to a sensor icon in the Preferences. So there's no separate property for "automatically ticked" and "ticked by the user". On a typical system the enabled list of sensor icons is much longer than the ones that actually get shown on the System Tray. You can open the AIDA64.INI file, and in there you can see that a lot of sensor icons (incl. many fan readouts) are enabled automatically, but they are not shown on your system simply because those fan headers do not exist or they provide a 0 RPM reading. Of course as soon as any of them start to provide a meaningful readout, the sensor icon will immediately appear on the System Tray -- and will not disappear until you restart AIDA64. Another problem with the behavior about stopped fans and invalid readings is that some users prefer to have the sensor icon (or OSD Panel, LCD, etc) items hidden in such cases, while others would still want to watch them show the invalid reading. And in many cases it's not easy to decide what an invalid reading actually is The hardware monitoring module of AIDA64 is very sophisticated, but your example shows that no matter how much we try to improve it, it still cannot satisfy every single specific and unique needs And when I say unique, I really mean that. The sensor icons module works the way it does now for many years, and noone complained about the 0 RPM fans issue before. And quite frankly, I have to disagree with you on the "critical" issue of stopped fans. While it is a critical issue, I don't think a user would quickly and easily notice that a fan stopped by looking at tiny 16x16 pixel System Tray icons. Unless of course you only use just one sensor icon, and you constantly watch the System Tray area for icon text changes I don't think in practice anyone would rely on the tiny sensor icons for critical system readouts. Typically, you would configure the Alerting facilty of AIDA64 to warn you about fan issues or overheating situations.

That's what I meant when I mentioned the difference between fan duty cycle (%) and fan RPM readout. Fan RPMs are shown in the AIDA64 System Stability Test, but fan duty cycles are not. So if your second GPU only provides a fan duty cycle, then it's normal that it will not appear in the System Stability Test Statistics.

Thank you. I think the issue is caused by an overflow in the AIDA64 sensor module. Somehow your D5 devices carry the same HID device ID and product string as MPS, and so AIDA64 tries to handle them as MPS. And since you've got five AquaComputer devices in total (incl. the Aquaero), the 4 slots that AIDA64 provides for AquaComputer devices overflow I've sent you a private message about this.

Thank you. There's something very fishy going on there. Please clarify: do you have a single Aquaero 5/6 device connected via USB, and you've got 4 MPS devices all connected via USB?

Please upgrade to the latest beta version of AIDA64 Extreme available at: http://www.aida64.com/downloads/latesta64xebeta If it doesn't help, then please post two Aquaero dumps (with a few seconds gap between them) to let us check what's going on on your devices

Such issue could be because Haswell-EP processors feature 2 memory controllers, each with 4 memory channels (total of 8 memory channels per socket). And there're many configurations where 4 memory channels are assigned to a socket, but not by utilizing all memory channels of the 1st IMC, but 2 channels for IMC0 and 2 channels for IMC1. And on the Cache & Memory Benchmark panel AIDA64 will show the utilized memory channels count for the very first IMC it can find in the system. You can go to the Motherboard / Chipset page to see all the IMCs you've got in the system, and check the actual memory channel utilization for all of them. Regards, Fiery

"MSI 2" seems like an incorrect (maybe truncated?) motherboard model. We can check it out, as well as the sensor issue, if you could post an ISA Sensor Dump of your system. Right-click on the bottom status bar of AIDA64 main window --> Sensor Debug --> ISA Sensor Dump. Copy-paste the full results into this topic. Thanks, Fiery

AIDA64 overrides its own CPU affinity setting to make sure it can enumerate all available processors and can measure various properties of all logical processors in the system. Regards, Fiery

PCH Diode temperature measurement requires the BIOS (UEFI) to properly initialize the thermal device of the PCH. I suppose on the Z97-GD65 motherboard the BIOS fails to initialize the thermal device, and so AIDA64 cannot use the device to measure the PCH Diode temperature. Regards, Fiery

Thank you, we've got the SDK, and ordered a X-52 Pro unit for development. In this topic I'll let you know about our progress on implementing support for it.

Note that fan speeds are only shown there when the actual RPM can be measured for the fan. Many fans are implemented in a way that only their fan duty cycle (%) can be detected, but the RPM cannot be measured. Regards, Fiery

Look, I completely understand your issue, but I suppose you didn't understand the issue about default behavior of the sensor icons when AIDA64 sensor icons weren't configured before. Please read my previous post again, and I hope you will understand the problem behind this whole thing.

The problem is about displaying values beyond 199, for any type of readings, on the sensor icons. Water level is easy, since it's a percentage value, so it can never have a value above 100. But, in case you say it's quite uncommon to have a liquid flow beyond 199 LPH, then it could work as a sensor icon. So we'll add support for flow sensor sensor icons in the next AIDA64 beta update There are quite a few issues with displaying stopped fans or 0 RPM readings. AIDA64 by default has a set of sensor icons and OSD items enabled, including CPU fan. In case a user enables the sensor icons or OSD Panel feature, and doesn't touch the selected items, then displaying a 0RPM reading for a disconnected fan may cause confusion when for example the CPU fan is connected to another fan header, or the CPU fan cannot be measured. The current solution is the best we could come up, this is the solution that suits both inexperienced and skilled users. It may still not be perfect, but for power-users we usually recommend SensorPanel and LCD over sensor icons and OSD Panel anyway, since those modules offer way more flexibility to satisfy special needs

That looks just fine. Those CPU core temperatures are quite good considering the CPU was under heavy load.

AIDA64 already supports monitoring battery level on the SensorPanel, but on your system a bit more tweakings had to be done to make it work. We'll implement the necessary improvements in the next AIDA64 beta update due in a few days from now. Regards, Fiery

Thank you for the dumps, the issue will be fixed in the next AIDA64 beta update due in a few days from now.

That's normal. Flow sensors provide such values that are not possible to squeeze into the 2 and a half character space that is provided by sensor icons. You can put percentage values there or temperatures, so a scale of 0 to 199 is fine. But such values like 99.99 or 12.34 will not fit in the tiny (16x16 pixel) tray icons. That's also normal. AIDA64 will not display a stopped fan, since it treats the fan disconnected on that particular fan header in such cases. That is due to a hardware limitation: PC fan headers do not have connection sense logic, so the disconnected state and fan stopped state cannot be distinguished We've checked the dumps, and it seems for some reason the temperature sensors called "stemp" (soft sensors) are missing from your second registers dump. So the Aquaero unit couldn't pick those temperatures up, hence it's not the fault of AIDA64. BTW, Aquaero 5 and Aquaero 6 are identical on the firmware, API and software levels, they only differ in hardware properties. Even the firmware provides a device ID that is the same for Aquaero 5 XT and Aquaero 6 XT. That's why AIDA64 identified your device as Aquaero 5

CPU power draw measurements and CPU Package temperature are reported only for the first processor in a SMP system. Regards, Fiery

It is normal, you don't have to worry about it. Chipset components like PCH, MCH, FCH and MCP tend to work at considerably higher temperatures than other motherboard components. Regards, Fiery