Fiery

We'll add the requested menu item soon in a new AIDA64 beta release. Do you log into HTML or CSV file? Thanks, Fiery

Yes, I wrote that, and since then we've made more test runs, and haven't found a reliable method that would provide 100% accurate results

APC PowerChute application can disable the classic Windows Smart Battery API. In such case AIDA64 will show no battery info on the Computer / Power Management page. We're already working on a solution for that, by utilizing the APC HID API to gather battery properties. Meanwhile, you can see the battery voltage and battery power load measurements on the Computer / Sensor page.

As I've stated, the Direct3D KMT calls do not provide the necessary information to calculate free video memory or total video memory. They only provide a used video memory data, and that's it.

Thank you for the feedback Regards, Fiery

We've fixed the RAID members enumeration with RST Enterprise v3 drivers. Make sure to upgrade to the latest beta version of AIDA64 Extreme Edition available at: http://www.aida64.co...07m7bnd8glcszip After upgrading to this new version, make sure to restart Windows to finalize the upgrade. However, I'm afraid that will not help about the SMART issue. Our contact at Intel suggested that there may be a bug about SMART pass-through in the latest driver releases, but he wasn't 100% certain about it. I guess we'll have to wait a bit more to get a sure confirmation on the driver bug. And some more to get a fixed driver I guess

Thank you for the data. We've fine-tuned the RAID handling, and extended the RAID Dump with a lot more debug steps and debug info. Make sure to upgrade to the latest beta version of AIDA64 Extreme Edition available at: http://www.aida64.co...07m7bnd8glcszip After upgrading to this new version, make sure to restart Windows to finalize the upgrade. Let me know how it works. In case its startup is still slow, then please let me know on the splash screen at which point does it "sit" too much. Is it "Scanning RAID Devices" ? Or does it wait a lot when the status display says "AIDA64" ? In case it is still slow to start, then please create a new RAID Dump and copy-paste the full results into this topic. Make sure to watch the status line on the bottom of the RAID Dump window, to see at which step does it become very slow. We've added a lot more steps to make it easier to pinpoint the actual RAID method that causes the slowdown on your notebook. Thank you for your time.

Thank you for the screen shot. We've implemented power draw and battery voltage measurement for APC HID UPS devices in the latest beta version of AIDA64 Extreme Edition available at: http://www.aida64.co...07m7bnd8glcszip After upgrading to this new version, make sure to restart Windows to finalize the upgrade. Let me know how it works Thanks, Fiery

Thank you for the data. We've done some test runs on a MSI N560GTX-Ti Hawk card, and found that the "GPU Ambient" measurement in AIDA64 equals to the "Memory temperature" measured by MSI Afterburner 2.2.0 Beta 11 (latest version).

Not all APC UPSes are capable of providing power draw measurement. Back-UPS RS and Back-UPS Pro Series should be able to provide that. Which APC UPS do you have? We're already working on the APC API. It will take a few more days to properly implement and test it.

I'm not sure why and how would that be useful

Thank you for the feedback. I'm glad it worked out. We'll try to provide proper support in the future too Thanks, Fiery

Thank you for the data. We've done some test runs, and it seems RST Enterprise drivers are unable to provide SMART information for RAID member drives. It may be a driver bug, but we're not sure. We've contacted Intel to ask for assistance. I'll let you know once we have an update to this matter. Edit: we've done more test runs with various RST driver releases to see if SMART calls work with them: - RST v10.5.0.1026: SMART calls work - RST v10.8.0.1003: SMART calls work - RST v11.0.0.1032: SMART calls work - RST v11.5.0.1109: SMART calls don't work - RST Enterprise v3.0.0.2003: SMART calls don't work - RST Enterprise v3.0.0.3020: SMART calls don't work - RST Enterprise v3.0.1.7016: SMART calls don't work So apparently from RST v11.5 and with all RST Enterprise v3 drivers SMART calls do not work anymore. Thanks, Fiery

Other users also had similar issues with Logitech Software v8.20.74: http://forums.aida64.com/index.php?/topic/631-not-working-anymore-on-g510/ For them a complete reinstall of Logitech Software helped. So it seems like it's not an AIDA64-related issue Regards, Fiery

We've added the ANGLE extensions in the latest beta version of AIDA64 Extreme Edition available at: http://www.aida64.com/downloads/aida64extremebuild1803jctz3gwqhrzip After upgrading to this new version, make sure to restart Windows to finalize the upgrade. Regards, Fiery

The Automatic Update feature will automatically update AIDA64 to the latest version -- without the need to manually download any ZIP or EXE packages -- if you have a valid AIDA64 license. During the evaluation (trial) period or when one tries to use a pirate license, AIDA64 will pop up a message box about the new version availability, but you have to manually download the ZIP package and manually perform the actual upgrade process. Even if you originally installed AIDA64 with the EXE package, the update link will still be provided to the ZIP package. Regards, Fiery

Thank you for the tests and your feedbacks. We've done more test runs today on various GeForce cards, and came up with a potential solution to this issue. Please upgrade to the latest beta version of AIDA64 Extreme Edition available at: http://www.aida64.co...03jctz3gwqhrzip After upgrading to this new version, make sure to restart Windows to finalize the upgrade. Let me know how it works. Please note that by simply unclicking the GPU test while running the SST, the clocks will not return to 2D profile, since unticking a subtest only suspends it, and the OpenCL session is not freed up. Only when you stop SST via the Stop button will the clocks return to 2D profile. With Radeon GPUs the clock management doesn't depend on an existing OpenCL session, but apparently it is simply based on GPU utilization. So when AIDA64 stops stressing a Radeon, the clocks will return to their 2D settings. While on GeForce GPUs you have to free up the OpenCL session to make ForceWare recognize that the GPU is not under stress anymore.

We've done some test runs on our own GeForce cards, and what we've found out is that ForceWare video driver apparently "forgets" to restore the clocks according to the 2D (power-saving) profile after the OpenCL GPGPU SST is finished. We've verified whether AIDA64 properly de-initializes and frees up all used OpenCL objects, and then unloads OpenCL DLL as well, but everything works as it is supposed to. On AMD Radeon cards and AMD APUs there're no such issues. We've also verified the GPU usage, and it gets back to cca. 0% after the GPGPU SST session finished. Hence the thread doesn't get stuck, and the GPU is not loaded at all. The higher temperatures are simply due to ForceWare keeping the 3D clocks profile in place until the application (AIDA64.EXE) is running.

No, it's not related to the GPU chip itself, but it's the temperature readout provided by the onboard CHiL CHL8228G buck controller chip. That chip also provides GPU VRM Current and GPU VRM Power readout as well.

Thank you for the feedback. But actually, the clocks do not reflect a stuck GPU stress test thread. The only sure verification is checking the GPU usage on the Display / GPU page. The clocks may be kept at high values (3D profile) by the ForceWare driver due to a driver bug. Please let me know if not only the clocks, but also the GPU usage gets stuck at a high value. Thanks, Fiery

Thank you for the feedback, and for your support

Thank you for your support. I hope you'll find AIDA64 useful in the next few years as well We have a lot of things on our roadmap, so expect to get some exciting AIDA64 updates soon. We do have plans about an online benchmark results interface for this year. Stay tuned As for RainMeter support, AIDA64 already offers multiple methods (Registry, Shared Memory, WMI) to expose AIDA64 sensor values to external applications. RainMeter's developers -- or anyone who has the necessary RainMeter API documentation -- need to develop the plugin that processes the values exposed by AIDA64 and "inject them" into RainMeter. I'm afraid we don't have the necessary developer resources to make in-house support for a wide range of 3rd party software. That's why we've come up with generic solutions (Registry, Shared Memory, WMI). Regards, Fiery

nVIDIA GPU clock settings are switched to 3D profile the first time AIDA64 detects the installed GPUs. So it's normal to have the clocks switched to high values once, but the driver (ForceWare) should restore the settings once the GPU is not under load. If you untick the GPU test during a stress test session, the log window should display "GPU1: Finished", and the video card shouldn't be under load anymore. You can check the GPU utilization on the Display / GPU page. If you don't want AIDA64 to switch to 3D profile, then you need to disable the option "Change to 3D profile on nVIDIA video adapters" in AIDA64 / main menu / File / Preferences / Stability. Please let me know if you find any issues about clocks or a stuck GPU stress test even after disabling the mentioned option. Thanks, Fiery

Thank you, we've fixed it up. Regards, Fiery

OpenCL GPGPU Stress Test has been implemented in AIDA64 v2.20: http://forums.aida64.com/index.php?/topic/660-aida64-v220-is-out/