Fiery

I'm sorry, I messed up the info on the alphabetical order. It is sorted, but since the drives are numbered with indexes, those indexes override the model ID of each drive. So if we gloss over the 3 groups issue (since your system only has drives in the first group), the order is the order that is dictated by the physical order of drives, as they are connected to their respective drive controllers, as well as the order of controllers. Since Windows may or may not enumerate drive controllers in the same order as AIDA64, only the order of drives connected to a particular drive controller should match between AIDA64 and Windows. Renaming of labels is available in OSD Panel, Desktop Gadget, SensorPanel, and external LCD modules.

We've tried to reproduce the issue on our own Ryzen test systems, but with no luck. Please do the following: 1) Before sleep, when benchmark scores are normal (lower), 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. 2) After waking from sleep, when benchmark scores are higher, please create a second CPUID & MSR Dump, and copy-paste the full results into this topic, or attach the results as a TXT file to your post. For those test runs, make sure to use the latest AIDA64 beta build: https://www.aida64.com/downloads/latesta64xebeta Thanks, Fiery

I'm afraid on some Asus motherboards the activity that AIDA64 needs to communicate with the EC (Embedded Controller) causes latency spikes. So far we haven't been able to solve the issue on our end So if you want to avoid the sound glitches, you need to disable EC support in AIDA64.

Thank you for the dumps. To me it looks like as if some of the GPUs in your system simply went to sleep after a while, due to lack of activity or load. Have you tried to disable ULPS?

Thank you for the details. We suspect it can be due to the video driver, so if it's possible, please try to downgrade ForceWare, to a late-2017 WHQL release, 388.31 for example. Let me know if it makes a difference. If not, please post a screen shot showing the error message that comes up when AIDA64 crashes.

We suspect it can be due to the video driver, so I'd try to downgrade ForceWare, to a late-2017 WHQL release, 388.31 for example.

I don't think so

What Windows version+build are you using?

You have too much free time

Exactly

Very strange. We've tried, but were enable to reproduce the issue with our SQL databases. Can you please check what happens if you purge your database (with either AIDA64 Database Manager or using a custom SQL query), and insert the report files to your database using the AIDA64 Database Manager?

Please avoid posting a single issue into multiple topics. I've replied you in your other topic.

The order is alphabetical, but it has 3 groups, and the alphabetical order is only valid inside each group. 1) First group is the internally connected drives (IDE/ATA/SATA drives) that are not enumerated by the AIDA64 RAID module. Usually those are the regular drives that everyone's got. 2) The second group is the internally connected drives that are either part of a RAID array, or not picked up by direct enumeration but only by the RAID module. It's important to note that those drives are not necesserily part of a RAID array, and may not even be connected to a RAID controller. I know, it's weird 3) The final group is the external drives (FireWire, USB, eSATA, Thunderbolt, etc). If you post a current ATA Dump and SMART Dump, I can tell you more about the why's of the ordering. Not really a good idea, since then the driver may override the otherwise more explanatory model ID with something useless. In your particular case (of the 280GB Optane 900P drive) it indeed would be useful though, but then again, it would be useful for many other SSDs that have no such "nice" model ID that can be understood by a glance, like for certain Samsung SSDs.

We'd rather wait for a public BIOS release for Prime X299-A. It's an essential machine in our test fleet (due to AVX-512 support and many CPU cores), so we'd try not to mess it up with a test BIOS

That spike was probably just a glitch in the communication between AIDA64 and the EC (Embedded Controller) chip of your motherboard that provides the "CPU" current and "CPU" power readings. While the "CPU Package" and "CPU IA Cores" readings are provided directly by the CPU, and there's no communication issue possible there, fortunately.

I'm not sure if you mean that the indication of thermal throttling is a bug in AIDA64 or something else. If you're doubtful about the validity of the throttling reporting, you can check it with alternative monitoring software as well. I'm sure they all will report the same amount of throttling though

It means whatever you've done to your system made things worse

We cannot add such readings to the hardware monitoring module simply because the UpTime statistics cannot be collected in a reasonable time span in all cases. If you have a huge event log with tons of entries, collecting UpTime statistics could take several seconds -- which is not acceptable when you have 1 second or even lower update rate for your external applications (or SensorPanel, OSD Panel, etc).

Sounds great, thank you for the info!

Thank you for the data and screenshot. What happens there is AIDA64 checks fan duty cycle (%) setting first, and when it's at 0%, it assumes the fan RPM reading should be zero. Are you sure the fan was spinning when you've done the dump?

What you can do is disable showing the AIDA64 main window in AIDA64 / main menu / File / Preferences / General, and of course to enable SensorPanel in the Preferences as well. Then you can launch AIDA64 by simply executing AIDA64.EXE (without any special command-line arguments).

There are several details that could be detected on a rooted device that are not available on regular devices. But we don't focus on those scenarios, simply because rooting is not a mainstream activity. PDF output is not available at this time, but you can convert reports after sending them in email into any format you wish.

It is most likely because under heavy stress your CPU is hitting the pre-configured TDP or power limits, and so it has to scale the clocks down to obey those limits. You can either unlock those limits to avoid such issues, and/or disable Turbo Boost and use 5GHz as the base clock for your CPU.

Those are not our products, so we cannot offer them for free.

Do you think it could be related to the Windows 10 major update of 1803? Also, please let us know more about your hardware configuration. Motherboard model, CPU type, HDD(s) / SSD(s), video card(s)... Thanks, Fiery