Fiery

Thank you

I suppose your overclock settings are a bit too much for your system to work stable. You need to lower the clocks and/or adjust the voltages and memory timings to make it stable. Regards, Fiery

NB Clock: I don't think it's a bug. By default, North Bridge clock is dynamically adjusted by the CPU, so it's not fixed at any certain value. Or do you have a fixed value configured in the BIOS Setup for it? As for the CPUID Panel, it's already quite crowded, so we're not planning to add any more information to it. As for Sensor Properties / Motherboard Name: it's not meant to show you the motherboard that you've got. It shows the codepath that AIDA64 uses to tweak the sensor readings to better suit your motherboard. The list of MSI product codes indicates that all those different motherboards use the same codepath for sensor tweakings. One of those IDs (MS-7976) is your motherboard of course On the DirectX Video page AIDA64 reports classic DirectDraw and Direct3D video adapter properties. Direct3D 12.x uses a different API that is currently not handled by AIDA64. You can see the DirectX hardware compliancy of your GPU on the Display / GPU page.

If it's possible, please right-click on the bottom status bar of AIDA64 main window --> Sensor Debug --> SMBus Dump (Full). Copy-paste the full results into this topic, or attach the results as a TXT file to your post. You may need to enable status bar in AIDA64 / main menu / View first. Please do that for both the latest beta (3916) and the latest stable build (3900). What we've done since Build 3900 is increased the timeout value for the IMC of your processor. In theory that would help about slow SPD devices, and it shouldn't cause any more troubles than before. It shouldn't make any SPD devices disappear However, previously we've already seen a few examples of X99 motherboards where the IMC had issues talking to the memory modules populated on the last (4th) memory channel. The last memory module (e.g. DIMM-D1) appeared in the list of SPD devices, but there were reading errors in the SPD block and that caused various issues about detection. For example, memory module part number was read incorrectly, or some of the timings were off. It would be important to check whether DIMM-D1 SPD block can be read without errors on your system, using Build 3900. Thanks, Fiery

We do have a very good relationship with Corsair, so you can definitely expect a resolution for this issue. What you're saying applies to most sensor devices, but Asetek LC based water coolers are the exception from the rule. You cannot just passively read values from them. You have to alter the fan duty cycle (%) value in order for the device to pass back the current fan RPM and pump RPM measurements. It's a very bad design for sure, one of those that are very hard to work with. But we've come up with an idea that we've proposed to Corsair. If they accept it, then there will be a very convenient solution to this issue that would enable any 3rd party software to talk to Asetek based Corsair water coolers without altering the duty cycle setting or even talking to the device directly. The only problem is -- although this doesn't affect your case -- that such a fix would only help with Asetek LC based water coolers made by Corsair. Competitors making water coolers based on the same Asetek LC hardware (for example: NZXT Kraken) would still suffer from the same issue with their respective manufacturer made software (e.g. NZXT CAM). But that's a case for another day I know quite a bit about the background of those software development issues that Corsair has been facing in the past few years, and I can tell you one thing for sure: recently they (Corsair management) have made huge strides to fix that. So you can expect their software to greatly improve as time goes by.

We've added the 3 new lines to the SSE header, as you've requested. We've also implemented the /api JSON API that you've requested, in the way you've proposed. With the sensors tag you have to list the sensor items in the way AIDA64 calls them, separated by comma. So an example URL might be: ipaddress:8080/api?callback=myCallback&sensors=SDATE,STIME,TMOBO Both the callback and sensors tag are optional. The only quirk is that you have to place all the items you need to access via /api to your RemoteSensor layout as Simple Sensor Items. You can find the new AIDA64 Extreme beta build at: http://www.aida64.com/downloads/latesta64xebeta After upgrading to this new version, make sure to restart Windows to finalize the upgrade. Let me know how it works

We've added several new timings for Skylake and Kaby Lake. Make sure to upgrade to the latest beta version of AIDA64 Extreme available at: http://www.aida64.com/downloads/latesta64xebeta After upgrading to this new version, make sure to restart Windows to finalize the upgrade. Let me know how it works. Please note that tWTR is a calculated value that cannot be directly detected. As tWTR AIDA64 shows the values that the BIOS Setup and ASRock's software calls tWRRD.

Okay, I think I understand the issue now. Currently, due to hardware limitations, AIDA64 can only work with an Asetek based water cooler if you use a fixed duty cycle (%) value. If you use dynamic fan control via CL Software, AIDA64 cannot work with your hardware, since there will be a constant collision between the hardware polling done by CL Software and AIDA64. The synchronization technique that the latest CL Software and the latest AIDA64 use help in every other case but this one. We've already dropped an email to Corsair, explaining this issue. There are multiple solutions fortunately, and hopefully we can pick the one that is suitable for all users. I will keep you posted in this topic, although things may go a bit slow since we're in the middle of summer right now. Until then, you need to either use a fixed duty cycle value, or disable Asetek LC sensor support in AIDA64 / main menu / File / Preferences / Stability.

Have you tried fixing the fan duty cycle (%) value in CL Software, and set the same percentage value as Asetek fan speed value in AIDA64 / main menu / File / Preferences / Hardware Monitoring? Downgrading is not necessary. I suppose this is a different issue than the "classic" hardware collision. We'll contact Corsair and try to find a solution with them.

We've tried to implement a workaround for such situations by doing exactly what you explained, ie. multiplying the reported resolution by the DPI scale percentage. But, it doesn't always result in the right resolution, e.g. 1707 * 2.25 = 3841 pixels (rounded). And since Windows supports any kind of Desktop resolution, it is not safe to assume the Desktop must be e.g. 3840 pixels wide, and that it cannot be 3841 pixels wide. Monitor resolution should be shown on the Display / Monitor page. AFAIK it's not possible to detect the full-screen resolution when you're running another software (not AIDA64) in the foreground.

Corsair Link Software keeps evolving, and we're adjusting AIDA64 to suit the latest CL Software version. If you install the latest CL Software and the latest AIDA64, they should be able to work together, without a collision. The next version of CL Software will be even more secure about avoiding collisions. Corsair Link sensor support refers to the CL Framework. It's when you have a CL Commander central unit and you hook your devices onto it -- rather than hooking up the same devices via direct USB connection. When you have devices connected via USB, the CL Framework is not utilized at all, and so altering the Corsair Link sensor support option does nothing. I know, it's quite confusing that both the CL Software and the CL Framework are called CL, but that's Corsair's choice on the technical term.

Do you mean we should add those 3 lines to the SSE response that starts with: HTTP/1.1 200 OK Content-Type: text/event-stream Cache-Control: no-cache

I'd start with: 1) Update motherboard BIOS to the latest one 2) Set memory module timings to a more relaxed setting, dictated by the classic SPD block rather than the XMP (Extreme Memory Profile). If that still doesn't help, then I'd try it with 2T Command Rate (tCR or tCMD) setting as well. If none of those help, it could still be a faulty memory module, a dying motherboard or a faulty PSU. Not easy to diagnose such issues though If you have a chance to borrow a reliable PSU, it would worth checking that too. Regards, Fiery

If you use a background image, then you have to adjust its size to make sure it is the same dimension than your SensorPanel. Magnification is not supported by the SensorPanel.

I'm afraid it's not possible to measure RAM clock speed under Android. Regards, Fiery

You can adjust the SensorPanel dimensions (width and height in pixels) in AIDA64 / main menu / File / Preferences / Hardware Monitoring / SensorPanel.

Thank you for the feedback

Please give us a few days to diagnose this issue, and to come up with a more detailed chipset detection code for Skylake. I'll get back to you in this topic once a new beta update to AIDA64 is available for you to try

We've already implemented the necessary synchronization techniques to make sure AIDA64 can work together with Corsair Link Software. If it still doesn't work as expected, then you can do the following: 1) Disable Asetek sensor support in AIDA64 / main menu / File / Preferences / Stability. That way however you will lose the sensor readings coming from H115i. 2) You can try tweaking the Asetek fan speed value in AIDA64 / main menu / File / Preferences / Hardware Monitoring. You only need to adjust the first percentage value in case you have a single water cooler. You may find a setting that would produce the same RPM output that you've configured in CL Software. Regards, Fiery

Please upgrade to the latest beta version of AIDA64 Extreme available at: http://www.aida64.com/downloads/latesta64xebeta After upgrading to this new version, make sure to restart Windows to finalize the upgrade. Let me know if it helps.

Thank you for letting us know about your workaround. We've tried to replicate the issue on our own test systems, but without a luck. I don't like to say it, but I really have no idea what's wrong on your system. Could be a timing issue, a BIOS pecularity or even a driver bug.

You can measure disk read speed and write speed, but not as a percentage (activity) value, but the amount of data being transferred in bytes/sec. AIDA64 supports all those readings, so you don't have to rely on the activity % value. You can simply rely on the Disk N Read Speed and Disk N Write Speed values

Not possible, since the activity percentage is reported as idle % actually. So when e.g. it is being reported as 29% idle, AIDA64 will show 71% activity.

Max/avg temperature highly depends on the type of computer, the kind of processor you use, the type of system case, the amount of overclocking you've applied, etc. etc. So there's no generic rule there. If you want to put temperatures further down, then the only way to go forward is to improve the ventilation of the system case, and/or to install water cooling. On the software level the only way is to reduce clocks and voltages.

Usually there are 2 questions that the AIDA64 System Stability Test should answer: 1) Is the system stable, even while running a very demanding task? 2) Is the system overheating under very high load? In your case, issue #1 is cleared, since the computer didn't show any abnormal behavior while running the test. As for #2, I can't see anything critical among those maximum temperature readings, so all is well. You can go on by analyzing minimum and maximum voltages, but in case they were hitting critical levels during the stress test, your computer would have locked up or Windows thrown a BSoD. Regards, Fiery