Fiery

I don't think you saw texture memory usage. Maybe it was local video memory and non-local video memory usage? Those values are listed on the DirectX / DirectX Video page. However, those cannot be detected under Windows Vista and Windows 7 anymore, due to architectural changes about how Windows handles video memory.

I've replied to that in your other topic. Please avoid posting the same issue into multiple topics (it's not easy to track things).

Please copy-paste the full content of the Display / Monitor page of AIDA64 into this topic. If it's possible, we'll add your monitor to the AIDA64 monitor database. FYI, not all monitors can be identified due to lack of identification data programmed into the EDID record of the monitor.

Maybe the mixup about the clocks comes from the fact that AIDA64 shows both real and effective clocks, while EVGA Precision only shows the effective clock? Slight difference between the configured clock and the actual clock may come from PLL inaccuracy. In other words, it's not always possible to configure the clock PLL to produce the requested clock, so 10-20 MHz difference is considered normal. As for the fan issue, you need to wait for EVGA to roll out a new Precision release that is properly synchronized with hardware monitoring software (e.g. AIDA64, HWiNFO32, SpeedFan, HWMonitor, etc).

Maybe EVGA Precision shows the effective clock, while AIDA64 shows the real clock. In fact, AIDA64 is supposed to show both real and effective clocks. Clock speeds for DDR memories can be interpreted differently

1) Please copy-paste the full content of the Computer / Sensor page of AIDA64 v1.50 into this topic. 2) Then right-click on the bottom status bar of AIDA64 v1.50 main window --> Sensor Debug --> ISA Sensor Dump. Copy-paste the full results into this topic. 3) Also right-click on the bottom status bar of AIDA64 v1.50 main window --> Sensor Debug --> SMBus Dump (Full). Copy-paste the full results into this topic. Based on that data we can check what happened to the temperature labels. Thanks, Fiery

Nothing has changed in AIDA64 v1.50 about the External Apps feature, so what worked with AIDA64 v1.20 should still work with AIDA64 v1.50. Make sure to enable that feature though, in AIDA64 / main menu / File / Preferences / Hardware Monitoring / External Applications.

Please check Q#10 in our Knowledge Base: http://www.aida64.com/support/knowledge-base Regards, Fiery

We've made an AIDA64 Rivatuner plugin that you can download from: http://www.aida64.com:8081/rivatuner_aida64_monitoring_plugin.zip

The requested items are implemented in the today's update for AIDA64: http://www.aida64.com/news/finalwire-rolls-out-aida64-v150 Regards, Fiery

It looks great, thank you for letting us know. Regards, Fiery

I guess the mixup came from the fact that you first obtained a free upgrade in our original campaign (that ran between Oct 06 and Oct 20). In that campaign EVEREST customers were entitled to receive a free upgrade to AIDA64 v1.00. The critical information there was: v1.00. Even though the free upgrade key then was intended to be used only for AIDA64 v1.00, it was good for AIDA64 v1.20 as well. But then it stopped working with AIDA64 v1.50. I guess your new AIDA64 upgrade license was then obtained using the current upgrade procedure, so it will be valid for the same maintenance period than your original EVEREST license. It means you can use it with AIDA64 latest version as well.

Please drop an email at the following email address, and our Licensing Department will check out what's wrong with your AIDA64 key. Make sure to indicate your name and AIDA64 license key, so our staff can identify you. upgrade AT aida64.com (replace AT with @)

Such temperature readings are usually read from the onboard sensor chip, but not from the usual CPU or Motherboard registers. So they could either mean a special temperature (e.g. PWM temperature, chipset temperature, DIMM temperature), or an invalid reading. You can check out the Computer / Sensor page to see if those 2 special readings are valid or not. Regards, Fiery

AIDA64 licenses are not limited by version number, but only by time constraints (maintenance limit). You can use AIDA64 v1.50 with the same AIDA64 license. You will also be able to upgrade to any AIDA64 beta or stable version that will be released before your maintenance period expires (Sept 2011). Regards, Fiery

Thank you for your kind words I'm sorry for the late reply, but we've been very busy with the new AIDA64 release we could finally roll out today: Regards, Fiery

The new AIDA64 update implements AVX-optimized benchmarks for the upcoming Intel Sandy Bridge processors, adds a brand new video encoding benchmark, and supports the latest AMD and nVIDIA graphics processors. New features & improvements - Support for the upcoming Intel Sandy Bridge desktop and mobile processors - AVX-optimized 64-bit fractal and security benchmarks - AVX-optimized System Stability Test module - 64-bit multi-threaded VP8 video encoding benchmark - Revamped ZLib data compression benchmark - GPU details for AMD Radeon HD 69xx and nVIDIA GeForce GTX 570 - Enhanced support for nVIDIA RAID controllers - Estonian localization Website enhancements AIDA64 Extreme Edition quickly became an indispensable utility for hardware reviewers all around the world. On the AIDA64 Testimonials web page professionals from Hungary, Romania, Russia, UK, and USA explain how AIDA64 helps their everyday job while analyzing and benchmarking various PC hardware components. [ Press Release ] [ What's new in AIDA64 v1.50 ] [ Download ]

Thank you. It's rather weird that it stalls at the nVIDIA RAID array. If it's not too much trouble, can you please try to perform the same HDD SPTI Dump with the USB card reader disconnected? It would be great if we can narrow this down to either the RAID array or the card reader. Thanks, Fiery

The confidential info may not need to be released. AFAIK DES 2 and DES Advanced applications use a NT service to measure power draw, and report it via a text file (INFO.DAT). Sounds like a way that could be used by 3rd party applications as well. However, the service stops reporting the values when the DES main application is not running So it's not really useful that way.

Thank you. Apparently, your card reader is already skipped by the SMART code, so it's a bit weird that it's still slow on your system. Please try to issue the following dump, and let us know how quick it is performed: right-click on the bottom status bar of AIDA64 main window --> Disk Debug --> HDD SPTI Dump. Copy-paste the full results into this topic. Thanks, Fiery

It's true that on the Sensor page you cannot adjust labels. But on the LCD you can rename all the labels, so I'm not sure what feature do you miss about the LCD setup

Please let us know more about your system configuration. 1) Windows version? 32-bit or 64-bit kernel? 2) SATA controller type? 3) Motherboard model? Thanks, Fiery

Please right-click on the bottom status bar of AIDA64 main window --> Disk Debug --> ATA Dump. Copy-paste the full results into this topic. Also right-click on the bottom status bar of AIDA64 main window --> Disk Debug --> Physical Drives Dump. Copy-paste the full results into this topic. --- As for the buffer size issue, I'm afraid that's just a common issue about SATA drives with 32MB or bigger DRAM buffer. It's an issue with the ATA IDENTIFY block provided by the HDD firmware, so we cannot fix it from AIDA64. Thanks, Fiery

Thank you for the feedback

1) I normally wouldn't bash another software, but now that you mentioned it ... AFAIK HWMonitor uses a rather twisted, not very scientific method to "measure" the CPU power consumption. It doesn't even work in several cases, e.g. on our Gigabyte 890GPA-UD3H motherboard + Sempron 140 system it constantly reports 40.50W for the CPU power, both idle and at full load. 2) DES has a lot more variations than what you listed. There's the old "classic" DES for the oldest boards with DES support, and there's the Easy Energy Saver for AMD processors. Every generation of DES/EES uses a different method to measure the CPU power, and they do depend on BIOS tables. Such BIOS tables may change between BIOS releases. As for stable readings, yes, our old DES method provided solid and stable readings in most of the cases, and users didn't even notice they were off. Sometimes they were off only at full load, sometimes they were off even at idle. Sometimes only by a few watts, other times the values didn't make any sense (like 0.15W at full load, or zero watts). The whole thing is just a big headache, and we invested valuable resources in this whole thing, pretty much in vain. Don't get me wrong, we would be very happy to implement DES/EES support again, but in order to do so, we need proper SDK or programming manual from Gigabyte.