Jump to content

Fiery

Administrators
  • Posts

    12405
  • Joined

  • Last visited

  • Days Won

    550

Everything posted by Fiery

  1. Are you sure Afterburner has no background task that would keep monitoring your sensor readouts, even after you've closed its main window?
  2. The CRC for the ZIP package is downloaded (acquired) from our update server, so it's not possible to manipulate the ZIP package. The CRC is not part of the ZIP package at all, and it doesn't necesserily come from the same download server either. We don't see a vulnerability there.
  3. It is rooted in It is rooted in the limitation of the chipset, since it can only handle up to 8 DIMM slots by default. So the SMBus mux is necessary to make sure it can handle up to 16 DIMMs slots (using a 2-way / binary mux). The SMBus mux of Intel S5500BC, S5520HC, S5520SC and S5520UR motherboards are handled by AIDA64. Rare exception, but it's there. The mux of a few Asus and Supermicro motherboards are also handled.
  4. We can implement any mux, as long as we get the technical guidelines on it. In case Lenovo is willing to help us out about that, we'd be happy to add a mux for your motherboard. It's a discontinued product, so if you ping the right person at Lenovo, there's a chance they figure there's nothing wrong handing out such details on an old-ish product...
  5. Sadly, most 2-way and 4-way server motherboards use a SMBus mux to handle the SPD for more than 8 DIMM slots. Such muxes are proprietary and not documented at all, so we can only support a few of them where we somehow could obtain the technical guidelines on handling the mux. I'm afraid we have absolutely no such information on any Lenovo server motherboards though, so we can only support them without handling the SMBus mux. It usually manifests as AIDA64 being able to detect half or 2/3 of the installed memory modules -- exactly as it is in your case.
  6. Yes, our automatic update system verifies the CRC for the downloaded ZIP package before extracting it and moving the files to replace the old files. Regards, Fiery
  7. 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
  8. Great minds read each other
  9. I've sent you my email address in private message
  10. 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).
  11. 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.
  12. 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
  13. 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
  14. 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
  15. 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.
  16. 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.
  17. 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.
  18. Thank you for letting us know about the root cause
  19. 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.
  20. 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.
  21. It's changed permanently, but the change is only applied after the first Windows restart after altering the Registry TdrDelay value.
  22. It must be due to temporary measurement errors. Do you have any other monitoring software running in the background?
  23. 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.
  24. Do you have issues about your new graphics card when you don't have AIDA64 running in the background?
  25. 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
×
×
  • Create New...