Fiery

Administrators
  • Content count

    6422
  • Joined

  • Last visited

  • Days Won

    210

Fiery last won the day on April 24

Fiery had the most liked content!

Community Reputation

251 Excellent

2 Followers

About Fiery

  • Rank
    AIDA64 Developer

Contact Methods

  • Website URL
    http://www.aida64.com

Profile Information

  • Gender
    Male
  • Location
    Budapest, Hungary
  • Interests
    AIDA64 :)
  1. Thank you for your ideas. We're not planning to enable animations simply because it would consume a lot of system resources to update the SensorPanel more frequently than 10 times a second -- which is the 100 milliseconds update rate that is available as the maximum update rate right now. A fluid animation would require 30 or even 60 updates per second. The custom gauge configuration is already too quirky and complicated, and we're not planning to make it even more complex by doubling the number of states. As for the update frequency, that's again, would require too much system resources. And on most computers polling all the sensor devices take more than 100 milliseconds anyway, so you would never be able to reach the desired 30 FPS update rate with the SensorPanel anyway
  2. Thank you for your help. The issue will be fixed in the next AIDA64 beta update due later this week. I'll post a message into this topic once the new beta is available for download.
  3. Thank you for the files. The issue will be fixed in the next AIDA64 beta update due later this week. I'll post a message into this topic once the new beta is available for download.
  4. We do have plans, but not for the near future. We're watching the market, the evolution of the Windows PC ecosystem, and we'll make our move to 64-bit once it will become necessary or mandatory. The 32-bit main binary is there because that's the best compromise. Having a 64-bit main binary wouldn't be a major benefit, but on the other hand it would raise a lot of issues. One such issue would be a considerably bigger distribution package, more than twice the size of the current ZIP and EXE package. That's because when you have a 64-bit main binary, you need to have all DLLs compiled to 64-bit as well -- while retaining the existing 32-bit DLLs for compatibility reasons. Another issue is that many interfaces and APIs that AIDA64 relies on have no 64-bit support. And so when you want to use such an interface/API from AIDA64, it works now, but it would stop working if the user switched to the 64-bit main binary. As for the name itself: it's there to separate the software from its predecessors, namely AIDA32 and AIDA16. While it's true that the main binary is still 32-bit, but the critical parts (modules) that truly benefit from porting 64-bit are already available in both 64-bit and 32-bit flavours. Those modules are the benchmarks and the stress test (AIDA64 System Stability Test).
  5. I've just sent you a private message about this
  6. Using AIDA64 v5.90, please right-click on the bottom status bar of AIDA64 main window --> System Debug --> USB 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
  7. Such "stolen" section of RAM is usually occupied by the video buffer of an internal (iGPU) or external (VGA card) video adapter. Check if you've got any special BIOS options about memory mapping, and try to enable it if you find such an option in the BIOS Setup.
  8. The next AIDA64 stable update is scheduled for May or June, although there are many factors that could delay that release, for example the recent changes in AMD and Intel CPU roadmaps. But please note that our beta builds are considered "quite stable", so you should give the latest one a chance
  9. Thank you for the data. Reading all the registers from Aquaero devices is a slow process. You can lower the update frequency in AIDA64 to 100 milliseconds, but reading all registers from your Aquaero device would still take over 800 milliseconds. So the lowest update rate you can achieve would still be over 1 second. We cannot fix that from our side, we simply have to live with slow USB protocols.
  10. It's not supported right now. You can however watch the minimum/maximum/average sensor readings on the Statistics tab of the AIDA64 System Stability Test. You can also use the Logging facility (AIDA64 / main menu / File / Preferences / Hardware Monitoring / Logging) to record the minimum/maximum/average sensor readings in a CSV or HTML log file.
  11. Thank you for applying. I've sent you the guidelines on AIDA64 localization in email.
  12. We only add those computers to the list of reference results that we own. That's the only way to make sure all results are reproducable, accurate and authentic. We've only got a single Broadwell-E system based on 6800K CPU. As for Apollo Lake, you're right. It was due to a bug, but now it's fixed. It will be included in the next AIDA64 beta update due later today
  13. We do have references to 4D Systems LCDs, but they are actually not supported. We'll fix that discrepancy to clear things up.
  14. The readings look fine to me. I'm not sure why one core is colder than another one that's very close to it. It's probably due to inaccuracies in Intel's DTS (Digital Thermal Sensor) solution. DTS was not designed to allow temperature monitoring, but rather to prevent the CPU from overheating. So it doesn't have to be 100% precise, as long as it can detect the situation when the overall CPU state is considered "too hot for normal operation".
  15. It is usually caused by one of the sensor modules taking too long to update the values. 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. Thanks, Fiery