Fiery

We've fixed the Haswell-E DRAM:BCLK ratio detection and all other DDR4 related issues in the latest beta version of AIDA64 Extreme available at: http://www.aida64.com/downloads/aida64extremebuild3143zrvflpc9mdzip After upgrading to this new version, make sure to restart Windows to finalize the upgrade. Let me know how it works

We've implemented CPU core clock measurement in the latest beta version of AIDA64 Extreme available at: http://www.aida64.com/downloads/aida64extremebuild3143zrvflpc9mdzip After upgrading to this new version, make sure to restart Windows to finalize the upgrade. Let me know how it works

We've implemented the copy-paste feature for LCD items in the latest beta version of AIDA64 Extreme available at: http://www.aida64.com/downloads/aida64extremebuild3143zrvflpc9mdzip After upgrading to this new version, make sure to restart Windows to finalize the upgrade. Let me know how it works

It should be there, that's the right path. What software/tool do you try to use the read the values from WMI?

CPU throttling is not a good thing, although on many Haswell-based systems it could be considered normal under heavy system load. Please don't confuse the throttling graph and the CPU utilization graph. They're included in the same area. The yellow graph is for the CPU utilization measurement, and the other graph -- green or red, depending on the throttling activity -- is for throttling.

USB devices have a lot of information encoded in their firmware, including vendor ID, product ID, manufacturer string, product string, serial number, etc. Since they're all stored in the firmware, they can all be set to any value by a simple firmware reprogramming. Making a USB-connected chip look like another chip (in the USB device information block) is quite easy unfortunately. Regards, Fiery

Have you read the customer review on that page? Also, it would be very important to check how many I2C devices can that dongle handle, and what electrical connections do you have to apply to connect those devices. Also, it would be important to check where the proposed sensor devices would get their power from. Because, unlike with USB, the I2C bus doesn't provide any power to connected devices. So the whole thing, including the hardware and software design could quickly become quite complicated. IMHO you may be better off with a ready-made solution, such a device complex that has everything already developed, and you just have to plug the pieces together. AFAIK Yoctopuce provides such solutions, but I'm not sure whether they provide all kinds of sensors that you would need for your project, like humidity and such.

Such devices typically use I2C connection. With most PCs it's not possible to connect your own I2C devices. That's because most PCs do not feature an I2C bus that would be available for the user to connect his own I2C devices. But, in case you find a solution to connect your I2C devices to your PC in any ways, please let us know the exact solution and provide us with an API or other documentation on how to talk to your I2C devices. We can implement virtually any kind of sensor devices in AIDA64, as long as the communication protocol is well documented, and reading out sensor information doesn't take ages. A couple of potential candidates on connecting I2C devices to your PC via USB port: http://www.harbaum.org/till/i2c_tiny_usb/index.shtml http://www.robot-electronics.co.uk/htm/usb_i2c_tech.htm http://mmdolze.users.sourceforge.net/use-a-lcd-with-twi.html http://www.sprut.de/electronic/pic/projekte/usb4all/usb4all_en.html But, you have to be careful with those: you have to verify how many devices you want to connect to the I2C bus, and whether a specific I2C --> USB converter could support that many devices. Or, you can see whether there're any ready-made solutions offered by the following companies: http://yoctopuce.com http://phidgets.com Yoctopuce has very interesting devices that could measure all sorts of things. AIDA64 already supports their OLED displays, as well as Phidgets LCDs -- but not those companies' sensor devices at this time. Another solution might be building your own USB-connected interface board, based on a Microchip or Atmel microcontroller, and hook up your I2C devices to that board. That solution would provide the most flexibility, but may also be the most expensive solution as well. And then there's using a Raspberry Pi as a slave device connected to your PC via USB port, etc. etc. It all depends on how serious are you about this project, and what exactly would you like to achieve.

The requested feature will be implemented in the next AIDA64 beta update It will be rolled out later this week. Regards, Fiery

I meant the 2 scenarios listed as "1)" and "2)" above. It's unlikely, but it could happen. You can try downloading some big files while running the AIDA64 stress test, maybe it will cause an issue...

I think the confusion about thermal testing is that AIDA64 offers more flexibility for stress testing, and sometimes users cannot find the optimal combination. Usually the FPU subtest alone could put the most thermal stress on modern processors. And if you enable more subtests (like CPU, Cache, etc), the thermal stress will not be that great. So it's best if you decide what do you want to use the AIDA64 System Stability Test for: 1) You want to find potential computing errors or other stability issues. In which case you should have a combination of subtests enabled, e.g. you can enable them all. 2) You want to see how well your cooling solution works by putting the most thermal load on your system. In which case you should have only the FPU subtest enabled. Additionally, if you have a discrete video adapter (one or more video cards), you can enable the GPU test as well. If your system can stand 8 hours with both test #1 and test #2, then I'd consider it quite stable

It doesn't do any harm if you run the disk test while using your computer. The disk stress test simply performs file reading operations, so nothing low-level and nothing critical is being performed.

The disk test uses separate processing threads, so you can use it along with the other subtests if you want. You can also issue that test after the other ones. Based on your description of the issue, I too don't think it's disk related. It sounds more like a PSU, motherboard or memory related problem. Regards, Fiery

The requested feature will be implemented in the next AIDA64 beta update It will be rolled out later this week.

Thank you for the feedback. We're constantly working on the already implemented LCD protocols, while in the same time keep adding new ones. So the whole LCD module evolves rapidly, and hopefully soon it will cater for everyone

I'm glad it worked out

Try to double-click on the GPU temperature item, and select the actual GPU temperature from the list of temperatures. It may be called "GPU Diode". Note that "GPU" temperature and "GPU Diode" temperature are different readings, so if your old video card supported "GPU" but the new one supports "GPU Diode", then you have to reconfigure the relevant SensorPanel items.

Thank you for the links. We'll definitely have to do a lot of measurements to find out where does our DRAM:BCLK ratio detection code have issues.

That is yet again due to the enermously slow SPD bank switching mechanism of DDR4 modules. We'll do our best to come up with a fixed AIDA64 beta in a few days from now. Sadly, we cannot do that without an actual test hardware on hand, since we have to tweak and optimize the DDR4 SPD bank switching code to make sure it becomes quick enough to let you use AIDA64 without any slowdowns.

Thank you, we'll fix the voltages in the next AIDA64 beta. Rampage V Extreme and X99-Deluxe brought many changes to the sensor layer, so it takes a bit of time for us to figure out the layout

Even though it looks like if it was frozen, AIDA64 doesn't actually lockup there, but just slows down due to the SPD bank switching being very slow on DDR4 modules. You have to wait cca. 10 seconds to let it go through, to let it scan all DIMM slots for any possible DDR4 modules installed, and then things will get back to normal. That scanning will only take place once per an AIDA64 session, but if you close AIDA64 and start it again, sadly it will have to do it again. We'll of course fix that as soon as our DDR4 platform arrives.

Thank you

It doesn't a make a difference whether you overclock your system or not. A stable system should be able to perform any subtests in any combinations, without an error.

You can use the AIDA64 System Stability Test subtests in any combination you wish Regards, Fiery

If it's a DDR4 system, then the long initialization is unfortunately normal at this time. It is caused by the new SPD bank switching mechanism specific to DDR4 modules. The bank switching unfortunately takes a lot more time than we've anticipated, usually 5 to 10 seconds at least, but maybe in your case it's even longer. We'll implement a workaround to put that delay down to less than a second as soon as our DDR4 system arrives. I'll post a message into this topic once a fixed AIDA64 build is available for download.