Jump to content

Fiery

Administrators
  • Posts

    12617
  • Joined

  • Last visited

  • Days Won

    566

Posts posted by Fiery

  1. 1) On your system AIDA64 gets confused, because you've got Asus AI Suite II installed, and -- I suppose -- you've renamed the fan labels in it.  When AI Suite II is installed, AIDA64 doesn't use its low-level EC sensor functions, and relies on AI Suite II calls to gather sensor information.  And that only works properly as long as you use the default labels.  You can revert back to the default labels, or uninstall AI Suite II to make the fans appear properly in AIDA64.

     

    2) Minimum, maximum and average sensor readings are available in the System Stability Test (main menu / AIDA64 / Tools / System Stability Test).  You can use the Clear button there to reset the values.



    Regards,

    Fiery


     

  2. I just had another chat with the support over at Mad Catz/Cyborg Gaming, and I got bad news, they dont have any plans to release a SDK for this keyboard. I was told in December 2012 that they would release the SDK in early 2013, and now they dont have any plans for it, pretty bad move from them if you ask me.

     

    Anyone considering to buy this keyboard to use with Aida64, dont buy it, there are other keyboards with support for Aida64.

    That's bad news, but thank you for letting us know about their decision.

  3. Thank you for the feedback.  As I wrote above...

     

    "But please note that the core temperatures are measured via the on-die temperature diode of your processor.  And most FM1, FM2 and AM3+ socket based AMD processors feature a hardware issue in their temperature diodes that yields to very low temperature readouts at idle -- usually way below ambient (room) temperature.  The measured core temperatures only make sense when the CPU is under load"

     

    ... core temperatures are independent from motherboard sensor calibration, and the issue you experience cannot be fixed from software, since it's a hardware issue.

  4. You're right, I'm sorry, I've mixed it up :(  The correct statement would be:

     

    "Hi-Speed USB Device Plugged into non-HI-Speed USB Hub"

     

    It means you've connected a USB 2.0 device into a USB 1.x port.  That however alone wouldn't mean the device doesn't function properly, since USB 2.x and USB 1.x devices and ports can be mixed in any combinations.

  5. Please upgrade to the latest beta version of AIDA64 Extreme Edition available at:

     

    http://www.aida64.com/downloads/aida64extremebuild2514g5l8npfkxbzip

     

    After upgrading to this new version, make sure to restart Windows to finalize the upgrade.

     

    Let me know how it works.  As for CPU Analog I/O and CPU Digital I/O voltages, they are unfortunately not measured via conventional methods, so we need to do a bit of research about them.
     

  6. "Hi-Speed USB Device Plugged into non-HI-Speed USB Hub"

     

    It means you've connected a USB 1.x device into a USB 2.0 port.  That however alone wouldn't mean the device doesn't function properly, since USB 2.x and USB 1.x devices and ports can be mixed in any combinations.

     

    If you believe your issues may be related to having an outdated device (due to it being only USB 1.x), try to ask your internet provider to replace the device with a more modern one.

     


    Regards,

    Fiery

     

  7. Please note that unlike 3DMark, Furmark or many other 3D benchmarks or 3D games, AIDA64 uses GPGPU compute tasks (via OpenCL) to put stress on the GPUs and APUs.  It means, it has to call OpenCL to first copy a block of memory from system memory into the video memory, then start a program that performs the actual computation, and then when it's finished, it has to copy the memory back from the video memory to the system memory, in order to let it verify the results.  And since all those tasks have to go through OpenCL driver, then the video driver (ForceWare in your case), the PCI Express link, and also the GPU itself, there's a lot of latency and bottlenecks involved in the process.  It effectively means the GPU may not be driven 100% constantly, but sometimes a downward spike may appear when the OpenCL driver, the PCI Express link or the video driver lags a bit.  That's normal, and can only be avoided by directly programming the GPU (which is impossible), or using a 3D scene instead of a GPGPU code.

     

    However, the advantage of GPGPU stress test over 3D scenes is that using GPGPU code it's much easier to stress all available GPUs simultaneously.

     

     

    Regards,

    Fiery

  8. As this actually is my area of expertise, that is exactly correct.  While it can be supported and some iteration implemented, it is still in proposal and pre-draft stages.  :D

     

    I'm glad you chimed in :) If it doesn't violate any protocols or NDAs, would you please share the pre-draft register locations and bit fields -- where the DevSleep capability and status can be detected -- with us?  Or shall we wait for the first public ACS-4 drafts to become available for download?

     

    Thanks,

    Fiery

  9. As I've explained above, such issues may happen when under heavy load the CPU intermittently provides invalid core temperature readings to AIDA64.  Such readings should be ignored.  As for GPU, I'm not sure what may cause that, but since the GPU TDP% reading is measured via nVIDIA driver calls, it depends on the driver whether it provides reliable and stable readings.

  10. What we need is those feature bits to appear in the ATA/ATAPI Command Set specifications.  But as it seems, it's not been propagated for ACS-3 (latest revision), so I guess we would need to wait for ACS-4 to be drafted.

  11. 1) 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.

     

    2) Also right-click on the bottom status bar of AIDA64 main window --> Sensor Debug --> SMBus Dump (Full).  Copy-paste the full results into this topic.

     

    3) Then right-click on the bottom status bar of AIDA64 main window --> Sensor Debug --> Embedded Controller Dump.  Copy-paste the full results into this topic.

     

     

    Thanks,

    Fiery

  12. 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.

     

    Using that data we may be able to calibrate the AIDA64 sensor module to better support your motherboard.  But please note that the core temperatures are measured via the on-die temperature diode of your processor.  And most FM1, FM2 and AM3+ socket based AMD processors feature a hardware issue in their temperature diodes that yields to very low temperature readouts at idle -- usually way below ambient (room) temperature.  The measured core temperatures only make sense when the CPU is under load.

     


    Thanks,

    Fiery
     

  13. Thank you, but we haven't found the actual method to detect the Device Sleep capability and status in any of the documents we've got.  It is possible via the IDENTIFY DEVICE command, but even the latest ACS doc doesn't mention Device Sleep, DEVSLP or DevSleep.  So we don't know which register to use.

×
×
  • Create New...