Fiery

Please right-click on the bottom status bar of AIDA64 main window --> Sensor Debug --> ISA Sensor 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

Great minds read each other

I've sent you my email address in private message

They seem to be helpful on this, which is indeed a rarity these days. Let's see if they could replicate the issue on their own test systems. If they ask you about it, feel free to let them know that we are more then happy to work with them to resolve this issue, as long as they're fine with communicating us directly (in email, preferably).

The problem with us reporting the bug is 2-fold: 1) We're not an actual customer to them, even though we own a few Razer test devices. 2) The sort of automatic response would be that it's the fault of AIDA64, and that we're using the protocol incorrectly. And since it's no way to downgrade Synapse (AFAIK) to an older release to check if it works, and then gradually upgrade to newer and newer releases in "baby steps", we alone cannot test this whole issue in the classic way. The classic way of bug-hunting is to go back in time until we can find a point where the protocol works fine on both ends -- but with the silly cloud and fully automated manner of Synapse, this isn't possible.

In the state where you've disabled all the unnecesary modules (in Preferences / Stability), please right-click on the bottom status bar of AIDA64 main window --> Sensor Debug --> Sensor Profiling 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. We need to see that to find out which sensor module causes the delays on your particular configuration. Thanks, Fiery

Make sure to enable Wake GPUs up at AIDA64 startup in AIDA64 / main menu / File / Preferences / Stability. You need to restart AIDA64 to apply the changes. Let me know if it helps. Thanks, Fiery

Yes, there are many Hash algorithms out there, and we've picked the one back in the day that was the most popular by the time. We can debate on whether it's outdated or not by today's standards, but picking just one of the many hashing algorithms would equally be as questionable There's no universal standard, so we have to pick one. We may relieve the current SHA1 based benchmark sometime in the future, but it won't happen this year for sure, since we're already pretty much booked up about improvements and new features until Santa comes

We've tested it on our Windows 10 x64 (Version 1703, Build 15063, latest patches applied) based system with the latest Synapse updates and also fully updated keyboard firmware. Keyboard was of course the DeathStalker Ultimate. We can confirm to see the same phenomenon that you've brought up, and our conclusion is that it's due to a bug in the Synapse framework. Please report the issue to Razer, it's their responsibility to fix this up.

Unfortunately AIDA64 (and other Windows software as well) has no control over the order of System Tray icons. You cannot rearrange them in any ways from software. You can show them or hide them, that's all. Everything else is taken care of by Windows itself.

We've already got a Hash benchmark for CPUs that also can harness hardware acceleration (IA SHA x86 instruction set extension) if available. We've also got OpenCL based GPGPU Hash benchmark in the AIDA64 GPGPU Benchmark Suite that you can launch from AIDA64 / main menu / Tools / GPGPU Benchmarks. IMHO we're pretty much covered on hash benchmarks without specifically targeting any certain cryptocurrencies individually.

Thank you for letting us know about the root cause

If you want to get rid of such delays, try to lower the LCD update frequency to 500 milliseconds or even lower, in AIDA64 / main menu / File / Preferences / Hardware Monitoring / Update Frequency.

The red indicates the amount of throttling activity while running the stress test. Throttling is used by your processor to prevent itself from overheating. So a non-zero throttling activity indicates that your CPU is running too hot, and throttles itself down (slows itself down) to prevent permanent damage. For mobile computers throttling under heavy stress is normal. But, when your computer is idle or under partial load, it shouldn't throttle at all. In order to challenge/verify that, you can have the AIDA64 System Stability Test window open, without starting an actual stress test process. Do some other stuff on your computer, like browse the web, edit documents, read and send emails. Once in a few minutes go back to the opened AIDA64 System Stability Test window and check if the bottom graph shows any throttling activity. It's easy to spot it, since the throttling graph will always stay green when there's no throttling detected. It turns to red as soon as any throttling activity is found -- and stays red permanently after that.

It's changed permanently, but the change is only applied after the first Windows restart after altering the Registry TdrDelay value.

It must be due to temporary measurement errors. Do you have any other monitoring software running in the background?

It's quite self-explanatory I believe There's a Windows video driver setting used for video driver recovery purposes. If it's set too low, the OpenCL kernel that AIDA64 uses for GPU stressing may cause Windows to think the video driver has stopped responding. In which case Windows would restart the video driver, which would then break the AIDA64 GPU stress testing cycle. So it's best to have the TdrDelay value configured at a high level. AIDA64 will check the TdrDelay value, and if it's lower than 8 seconds, it will show you that popup warning message. If you let it fix the issue for you, it will increase the TdrDelay value to 8 seconds.

Do you have issues about your new graphics card when you don't have AIDA64 running in the background?

It could be because Windows was trying to activate the screen saver or lock screen while the test was still running. But, since the AIDA64 stress test is quite demanding, Windows itself may not have gotten the enough number of CPU cycles to use its own features about updating the Desktop. Either way, in case the test kept going on, no error was reported, and the computer didn't lock up or powered off, it is still a stable system

There's no fix for that I'm afraid. On its Nexus and Pixel devices Google -- for whatever reason -- decided to further limit apps access to certain system directories, like the ones necessary for temperature measurement. So now it's not possible to read any temperatures but the battery temperature. It applies to any apps running on your device, not just AIDA64.

Generally speaking, AIDA64 supports more sensor devices than HWMonitor, and collects more sensor readings from those devices. It may not explain the higher CPU load on your particular system configuration though. For example, on my main work computer, which is a Core i7-6700K + Gigabyte Z170X-UD3 based run of the mill desktop PC, both AIDA64 and HWMonitor consumes cca. 2% CPU cycles, both with 100 milliseconds update rate. There's no noticable difference between their impact on the system. You can lower the 1000 millisec update rate to 100 millisec in AIDA64 / main menu / File / Preferences / Hardware Monitoring / Update Frequency. You can track Current / Minimum / Maximum / Average readings by using the Statistics tab of the AIDA64 System Stability Test feature that you can launch from AIDA64 / main menu / Tools. Regards, Fiery

Such anomaly could indeed happen when you connect/disconnect external drives on-the-fly. It's not possible to lock the drives to a particular ID, but we can check what's happening with your drives in details, and possibly come up with a workaround. Because external drives are supposed to be the last ones in the list of drives, and so the IDs for the internal drives shouldn't be affected by connecting/disconnecting external drives. Maybe in your system the internal and external drive IDs are mixed together for some reason. Please right-click on the bottom status bar of AIDA64 main window --> Disk Debug --> ATA 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. Then right-click on the bottom status bar of AIDA64 main window --> Disk Debug --> SMART Dump. Copy-paste the full results into this topic, or attach the results as a TXT file to your post. Finally, right-click on the bottom status bar of AIDA64 main window --> Disk Debug --> RAID Dump. Copy-paste the full results into this topic, or attach the results as a TXT file to your post. Please repeat those dumps after disconnecting your external drive, so we can check how the list of drives and their IDs change. Thanks, Fiery

Yes, those sensor items are already available in the System category. They're called: Desktop Resolution and Vertical Refresh Rate

Please right-click on the bottom status bar of AIDA64 main window --> Disk Debug --> ATA 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. Then right-click on the bottom status bar of AIDA64 main window --> Disk Debug --> SMART Dump. Copy-paste the full results into this topic, or attach the results as a TXT file to your post. Then right-click on the bottom status bar of AIDA64 main window --> Disk Debug --> RAID Dump. Copy-paste the full results into this topic, or attach the results as a TXT file to your post. Finally, right-click on the bottom status bar of AIDA64 main window --> Disk Debug --> Disk Controllers Dump. Copy-paste the full results into this topic, or attach the results as a TXT file to your post. Thanks, Fiery

We don't really want to implement separate indicators. It would involve adding 48 new sensor items (6 reasons multiplied by 8 GPUs). We're thinking more in the line of simply returning the reason bit mask as it is passed by ForceWare. It would work like: a value of 1 means Power Limit, 2 means Temperature Limit, 4 means Reliability Voltage, 16 means Utilization, etc. A value of 3 would mean Power Limit + Temperature Limit occuring in the same time, and a value of 7 would mean Power Limit + Temperature Limit + Reliability Voltage occuring in the same time. I'm not sure however how you could define a proper LED colour assignment to make it useful for your purposes.