Fiery

We've added the requested hardware monitoring item in the latest AIDA64 beta update: https://www.aida64.com/downloads/latesta64xebeta Regards, Fiery

Steam is not our software, so I have no idea how it works. It may use an internal module to measure FPS.

Thank you for the feedback. Try to enable DIMM thermal sensor support in AIDA64 / main menu / File / Preferences / Stability, and restart AIDA64 to apply the changes. If it still doesn't work, then your memory modules are not DIMM TS capable.

It depends on what kind of operating system you're running. You can check the assignment of real and virtual cores on the bottom of the Motherboard / CPU page. CPU utilization means the average CPU utilization. CPU temperature is measured by the motherboard sensor chip, and it is usually an external CPU package temperature. Regards, Fiery

Thank you for the feedback

We will implement support for 360 TS in the next AIDA64 beta update due next week. Regards, Fiery

Thank you. It's puzzling. I think we have to leave it as is now. If the issue returns, please check the DIMM temperatures and SPD memory details for all DIMMs using AIDA64 + CPU-Z + HWMonitor + HWiNFO64 as well, to check if this is a hardware collision that affects any software polling DIMMs, or a bug in AIDA64. And then please let us know about the results in this topic

AI Suite collides with AIDA64, and it is especially dangerous on ROG motherboards like yours. Such collisions could well cause system instability, so it would be best if you completely uninstalled AI Suite.

Do you have Asus AI Suite installed?

Thank you. Do you happen to have any other software or service running in the background that you reckon might also monitor DIMM thermal state? Or are there any kind of monitoring, tweaking or overclocking software, or remains of such software installed? Like AI Suite background service?

Are you running your CPU at the same settings (clock-wise) than before? Is it similarly overclocked? Is the memory running at the same clock and uses the same timings as before?

Thank you!

Thank you. That still seems to be a mysterious issue. It does affect multiple users, not just you, so it should be a bug in AIDA64. Can you please check if HWiNFO64 can read all DIMM temperatures reliably, over a few minutes period of time?

Thank you. The register output seems fine. Are you sure you don't have a custom TJMax value configured in AIDA64 / main menu / File / Preferences / Hardware Monitoring? The TJMax setting there should be set to Automatic, since your CPU can provide the right TJMax value via a CPU register.

That option no longer works, and we'll remove it soon. We're now using a single set of icons. Regards, Fiery

The mentioned new AIDA64 beta update is available for download at: https://www.aida64.com/downloads/latesta64xebeta Let me know how it works.

Yes, it does. It doesn't utilize the middle steps at all. Of course if a certain software doesn't measure the CPU clock the right way, it could show something that your CPU doesn't do at all. If during the CPU clock measurement the CPU switches its multiplier up or down, and the measuring software is not aware of that, the measured CPU clock will not reflect the actual state of the CPU, but something in between the old state (before the software started to measure the clock speed) and the new state (after the software is done with the measurement). The measured MHz value will be in between the old clock and the new clock, so it will reflect a multiplier that the CPU may not switch to, at all, ever. Not to mention the issue that I've mentioned before, ie. when the CPU clock measurement code itself causes the CPU to switch its multiplier up or down (most likely up).

As I've explained above, clearly AIDA64 + CPU-Z + HWMonitor measure CPU clock using a different method than what Task Manager and MSI Command Center use. I still have no other choice but to stick to my stance about AIDA64 (+ CPU-Z + HWMonitor) measuring CPU clock using the right (proper) method. I don't know what exactly the other 2 software do, and frankly I don't care, since I'm 100% sure they do not use a superior CPU clock measurement method than our software. Why do you need your CPU to run at e.g. 3500 MHz when you overclock it? I thought you want it to be quick. It is quick even when it is running at a fixed clock all the time -- as long as that single clock speed level is high enough, of course.

We've just rolled out the first AIDA64 beta with proper handling of DPI scaling, as well as fix for the screen resolution detection issue: https://www.aida64.com/downloads/latesta64xebeta A few icons are left to be updated, and we also have to fix a few issues in the Monitor Diagnostics module. Let me know how it works on your system

We've just rolled out the first AIDA64 beta with proper handling of DPI scaling. In other words, it is fully DPI aware now: https://www.aida64.com/downloads/latesta64xebeta A few icons are left to be updated, and we also have to fix a few issues in the Monitor Diagnostics module. Let me know how it works on your system

We've just rolled out the first AIDA64 beta with proper handling of DPI scaling: https://www.aida64.com/downloads/latesta64xebeta A few icons are left to be updated, and we also have to fix a few issues in the Monitor Diagnostics module. Let me know how it works on your system

What I'm saying is that since on our motherboard -- and also several other motherboards with the same chipset and same CPU -- AIDA64 can track the CPU changing multipliers in the right granularity, there's nothing wrong with the software. There must be a configuration issue or other pecularity on your system that makes your CPU use only a small number of multiplier steps. First, please tell me why would that be beneficial? Your CPU seems to be able to utilize its power management features properly, so at idle it can down-clock itself to save power (it can switch to LFM). It can also switch up to the right high multiplier (it can switch to HFM) when the system is under load. What's wrong with it then? Why would it be beneficial to use the middle multiplier steps? And even if you miss those, what can we as software developers do about it? If there was a simple solution, I'd of course reveal it for you, but I've never seen a LGA2011 CPU behave like yours. To me it seems like a firmware (BIOS) issue or system configuration issue. If one can even call that an issue When both LFM and HFM modes work, ie. the CPU can both provide the expected performance and operate with little power at idle, I'd say it's working properly.

I'm the lead developer behind AIDA64, hence I know how that software works and what exactly it does. I'm not the developer behind Windows Task Manager or MSI Command Center, hence I have no idea what they do and how they work. I can only guess, but that's just a guess. I've already told you what I think they do: they measure average CPU clock over a certain period of time (short period, but still a period of time), and not the actual CPU clock frequency at a certain moment. Your CPU will never work at 4022 MHz when you use 100 MHz BCLK, so that single reading alone means MSI Command Center doesn't measure the CPU clock frequency in the proper way. It seems you stick to debating whether "proper" is really the way it should work. AIDA64 has its roots going back to over 20 years. It does it in a way that we believe, according to our over 2-decade experience, is the right way. CPU-Z, HWiNFO and several other monitoring software use exactly the same method to measure CPU frequency. BTW, CPU-Z and HWiNFO are also not exactly newcomers in this business. If you believe MSI Command Center and Task Manager both do a better job than AIDA64, CPU-Z, HWiNFO and other 3rd party monitoring software, then we have to agree to disagree. If this single issue -- where in my opinion you're clearly wrong -- is a make or break issue about using our software, then I'm afraid the only possible solution is for you to request a refund, get your money back, stop using AIDA64, and keep using Task Manager and MSI Command Center instead. Because we cannot and would not switch to using an average CPU clock frequency measurement method. Our method is the best and proper way to do it, and we wouldn't settle with an inferior solution.

In your video I cannot see any miscalculated frequency readings in AIDA64. 4499.8 MHz instead of 4500.0 MHz exactly is due to slight fluctuations in the BCLK (APIC Clock) reading. It's way less than what I've mentioned above. MSI Command Center miscalculated (or incorrectly measured) the core clock frequency by almost 22 MHz. And even if it does that, the BCLK should be adjusted in a similar fashion. "100.0 x 40.0 = 4021.7" is not something you could take as mathematically correct.

Please right-click on the bottom status bar of AIDA64 main window --> CPU Debug --> CPUID & MSR Dump. 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. Thanks, Fiery