Fiery

You can try uninstalling AI Suite II to see if it causes any lags, but most of the lags during benchmarking and stressing your system are simply caused by the benchmark module of AIDA64 that really and actually uses up 100% of system resources. So there's very little system resource left for the Windows management subsystem and the rest of the operating system functions.

AIDA64 Disk Benchmark handles physical drives, as they are managed by Windows. In case you have a RAID array defined, the RAID array will appear as a single physical drive in Windows, hence AIDA64 will treat it as a single drive, and will benchmark it as a single drive. In such case e.g. for a RAID0 array of 2 drives, both drives will be benchmarked in the same time, and their theoretical performance will be added up (aggregated). If you have a RAID array defined, there's no way to benchmark the individual drives (member drives) separately. AIDA64 also doesn't have file system benchmarks, so for example you cannot benchmark C: drive or D: drive separately, if they're 2 partitions of a physical drive. Regards, Fiery

Battery Charge Rate is already amongst the available SensorPanel items, in the Powers group. Regards, Fiery

That lag is there when you have the GPU subtest enabled in the AIDA64 System Stability Test. The lag is caused by the video driver, when a heavy OpenCL GPGPU computation load is in progress. The GPU stress test uses such a task to drive the GPU(s) to maximum performance and heat them up as much as possible. Regards, Fiery

Thank you. Do you have any RAID arrays in your system, or any Logitech Gaming Keyboard (with a LCD) connected? Where do you get the application errors? Just by leaving AIDA64 running, they pop up? Or do you browse between various AIDA64 pages, and sometimes the error comes up?

It's there Just look for the following 2 lines: Hardware Lock Elision (HLE) Restricted Transactional Memory (RTM) Regards, Fiery

1) Do you remember from which AIDA64 beta did you upgrade from? 2) What processor do you have in your PC? Thanks, Fiery

1) What version of AIDA64 do you have installed? 2) What version of Windows do you have installed? 32-bit or 64-bit? 3) What processor do you have in your PC? Thanks, Fiery

Such issues may happen when under heavy load the CPU intermittently provides invalid core temperature readings to AIDA64. Such readings should be ignored, and in fact in new AIDA64 v3.00 release we've implemented a special workaround for such situations. So with AIDA64 v3.00 you most likely will not have such downward spikes, or at least much less frequently than before. Regards, Fiery

On notebooks that option doesn't have an effect, so leave that option disabled (unchecked). Such temperatures are absolutely normal for notebooks and tablets, no need to worry about them. Regards, Fiery

Thank you, let's hope you can do magic to get Asus reveal their magic

The new block-random latency benchmarks take 10 seconds for each cache levels + memory, so on a L3 cache capable CPU the cache & memory latency benchmarks alone would run for at least 40 seconds. The bandwidth benchmarks usually run a bit quicker than 10 seconds, so roughly a minute for all benchmarks to complete sounds about right. On our Core i7-3770K Ivy Bridge + Dual Channel DDR3-1600 system it takes almost exactly 1 minute to run all tests.

With server systems it's much more difficult to get close to the theoretical maximum of memory bandwidth than with 1-socket systems. You also need a high CPU core clock speed and 6+ cores to drive the memory closer to its limit. The pair of X5550 processors we have in the Supermicro X8DTN+ motherboard have a relatively low clock speed of 2.66 GHz, and only 4 cores per socket.

We'll check what's going on about Haswell. On our Haswell system, and on many others where our partners "test-drove" AIDA64 v3.00, it works flawlessly. AVX1 and FMA4 optimizations are of course utilized for AMD Trinity, Richland, Vishera and Kabini/Temash/Kyoto.

The new memory bandwidth benchmarks are NUMA-aware, so on a 2-socket system where each socket has its own 3-channel memory interface, the performance of the 6 memory channels will be aggregated in the memory benchmarks.

Please check the following forum topics: http://forums.aida64.com/topic/1328-aida64-v300-is-out/ http://forums.aida64.com/topic/1326-new-cache-and-memory-benchmarks-in-aida64-v300/

The new AIDA64 release introduces completely rewritten memory bandwidth and memory latency benchmarks, optimized for AVX2, AVX and SSE capable AMD, Intel and VIA processors. The latest AIDA64 update also implements optimized 64-bit benchmarks for AMD "Kabini" and Intel "Haswell" processors, and supports the latest AMD Radeon and nVIDIA GeForce graphics accelerators. New features & improvements Multi-threaded cache and memory bandwidth benchmarks with AVX2, AVX and SSE optimizations Block-random cache and memory latency benchmark Optimized 64-bit benchmarks for AMD "Kabini" and "Temash" APUs AVX2 and FMA optimized 64-bit benchmarks for Intel "Haswell" processors Preliminary support for L4 cache of Intel "Crystal Well" processors Crucial M500, OCZ Vertex 450 SSD support GPU details for AMD Radeon HD 7990 "Malta" and nVIDIA GeForce 700 Series [ Press Release ] [ What's new in AIDA64 v3.00 ] [ Download ]

On our Z77-based Ivy Bridge Core i7-3770K system, with Dual Channel DDR3-1600 RAM we got the following scores using AIDA64 v3.00: Memory Read / Write / Copy / Latency: 23559 MB/s / 24093 MB/s / 22772 MB/s / 57.5 ns L1 Cache Read / Write / Copy / Latency: 461 GB/s / 231 GB/s / 460 GB/s / 1.1 ns L2 Cache Read / Write / Copy / Latency: 244 GB/s / 149 GB/s / 216 GB/s / 3.3 ns

We don't have any deep technical specifications on that motherboard, so all we can use is the information that AIDA64 reports on the Chipset page. Based on that, I'd say that the north bridge (X58) handles the Marvell 88SE9123 SATA3 controller and the USB 3.0 controller, both using a x1 PCIe link. The rest of the PCIe ports of the north bridge seem to be reserved for the x16 slots, handling video adapters. The south bridge (ICH10R) seems to only handle the JMicron JMB363 SATA2 controller, via a x1 PCIe link. The Intel 82567V-2 Gigabit NIC seems to use PCI connection, and not PCIe, so it will not reserve any PCIe links in the chipset.

We're rolling out a new major update to AIDA64 on June 03, 2013. It will feature the usual improvements to support the latest and greatest hardware technologies, such as GPU details for AMD Radeon HD 7990 "Malta" and nVIDIA GeForce 700 Series, and optimized benchmarks for AMD Kabini/Temash and Intel Haswell. On Haswell AIDA64 v3.00 will utilize all new instruction set extensions, so the benchmarks and the System Stability Test will also use the appropriate AVX2, FMA and BMI2 instructions. But more importantly, we've replaced the outdated set of memory benchmarks with brand new ones. The new bandwidth (read, write copy) benchmarks now use multiple threads to squeeze out every last bit of performance from the caches and the memory modules. On modern multi-core processors, using the old single-threaded benchmarks you couldn't see the actual memory bandwidth, but only the memory bandwidth available for single-threaded applications. With the new benchmarks you will however get considerably higher scores, much closer to the theoretical memory bandwidth available. It is especially true for 3-channel and 4-channel memory configurations, such as Intel X58 and X79 based high-end desktop systems; and also for NUMA-enabled multi-socket systems, such as 2- and 4-way AMD Opteron and Intel Xeon based servers and workstations. For example: Core i7-3960X with X79 chipset and 4-channel DDR3-1600: - AIDA64 v2.85 Memory Read: 16825 MB/s [ old ] - AIDA64 v3.00 Memory Read: 45640 MB/s [ new ] We've also implemented multi-threaded cache benchmarks, that now include support for the latest AVX and AVX2 instruction set extensions. Thanks to using all CPU cores for the cache benchmarks, you will get dramatically different cache bandwidth scores than with the old benchmarks. For example: Core i7-3960X with X79 chipset and 4-channel DDR3-1600: - AIDA64 v2.85 L1 Cache Read: 121.8 GB/s [ old ] - AIDA64 v3.00 L1 Cache Read: 674.7 GB/s [ new ] And thanks to the 2x widened L1 cache bandwidth of Intel Haswell, on these new processors using the new cache benchmarks of AIDA64 v3.00 you will get unusually high scores. Using Haswell, with a hint of overclock it's quite easy to cross the 1 TB/s mark for the L1 cache We've also replaced the old cache and memory latency benchmark with a brand new one that uses a different approach, recommended by processor architecture engineers. The old memory latency benchmark used the classic forward-linear solution, so it "walked" the memory continuously, in forward direction. Unfortunately that classic approach was sometimes over-optimized by "too smart" memory controllers, that led to unrealistically low latency scores. It was a constant fight for us to get around those over-optimizations, to make sure AIDA64 provides stable and reliable latency results. With the new latency benchmark we've switched to a block-random solution, that keeps "jumping" to random addresses inside a memory block for a period of time, and then skips to a new block and continues "jumping" to random places inside there as well. With this new solution memory controllers cannot find a pattern anymore in the latency measurement, and so they cannot over-optimize the benchmark. The block-random approach however means that latency results will be higher, and since the scores are in nanosec, it means the results will be worse than what you got used to. For example: Core i7-3960X with X79 chipset and 4-channel DDR3-1600: - AIDA64 v2.85 Memory Latency: 55.9 ns [ old ] - AIDA64 v3.00 Memory Latency: 67.5 ns [ new ] AIDA64 v3.00 also supports benchmarking the eDRAM L4 cache of the upcoming Intel Crystal Well processors. An interesting article about Crystal Well: http://www.anandtech.com/show/6993/intel-iris-pro-5200-graphics-review-core-i74950hq-tested Less radical change, but still deserves a note: we've also revamped the framework around the CPU ZLib benchmark, so you can see a few percent gain in performance using AIDA64 v3.00. For example: Core i7-3960X with X79 chipset and 4-channel DDR3-1600: - AIDA64 v2.85 CPU ZLib: 418.3 MB/s [ old ] - AIDA64 v3.00 CPU ZLib: 444.5 MB/s [ new ] We hope you'll find the new AIDA64 release useful. Feel free to ask any technical or not-so-technical questions about AIDA64 v3.00 benchmarks in this topic. Regards, Fiery

Since the exception seems to be related to NTDLL.DLL, we've added stronger exception handling for every calls in AIDA64 that uses NTDLL.DLL. It will be implemented in the next AIDA64 stable release due tomorrow

Please note that when you install an IPMI driver, the sensor readings should appear on the Computer / IPMI page in AIDA64. If you ask a technical person at Asus, please try to find out what methods are necessary to perform to read fan speeds (RPM) on your motherboard from a 3rd party software. As far as we can tell, none of the known methods apply to your motherboard, so it's quite a special piece of kit Usually there are 5 different ways to acquire sensor readings: 1) ISA port I/O 2) SMBus 3) Embedded Controller 4) IPMI Sensor 5) ACPI query Some motherboards use just a single method, while on others one needs to combine multiple methods to read all sensor readings. If Asus tech.support could tell us which method to use, and which registers belong to the fan speeds, then we can implement that in AIDA64 to let you measure fan speeds in AIDA64. However, based on our previous experiences with Asus, I doubt they would reveal their "cards" about this or any other Asus motherboards Asus tends to use proprietary methods about sensors, and they almost never publish any technical details on what they do and how they do it.

That issue is already fixed, so make sure to upgrade to the latest beta version of AIDA64 Extreme Edition available at: http://www.aida64.com/downloads/aida64extremebuild2460x8f2dmshtbzip After upgrading to this new version, make sure to restart Windows to finalize the upgrade. Let me know how it works

That's normal, and it is due to the lag of the video driver.

That's great, thank you for letting us know!