Jump to content

JcRabbit

Members
  • Content Count

    16
  • Joined

  • Last visited

Community Reputation

0 Neutral

About JcRabbit

  • Rank
    Member
  1. No worries, I am a developer myself so I won't be pestering you about this lol. You have all the time in the world.
  2. Wow. That is far more than I ever expected. Thanks, Fiery.
  3. Thanks for the reply, Fiery. I think this is the result of APC/Schneider Electric switching to the Modbus protocol and for some reason no longer providing all the information the older SmartUPS models did when using the Microsoft HDI Battery driver. My guess is that APC's own PowerChute software would display this extended information, but I don't want to install it because Powerchute replaces the Windows HID drivers with APC's own proprietary drivers. I was basically wondering if you guys knew anything about this Modbus protocol, as judging by what I read in those Linux forums
  4. I guess you won't be saying anything, then (although a simple 'I don't know' would have made me feel better than just being ignored lol). My other guess is that APC was using a SmartUPS protocol in their older products (like the SUA2200I), which was supported, and that AIDA64 does not support the 'new' ModBus protocol. No idea if that's actually it though, but I guess so. Happy New Year to everyone and may this terrible 2020 year and all its catastrophes soon be well behind us! Stay safe!
  5. Fiery, can confirm this. Currently MSI Afterburner v4.6.2 Beta 4 reports 28C and AIDA64 reports 30C. 1. I have a Asus Strix 3090 OC. 2. Asus ROG Maximus XI Formula motherboard 3. Using AIDA64 v6.32.5600
  6. Hey Fiery! I just replaced my 11 year old APC SUA2200I Smart UPS with a brand new APC SMT2200IC Smart UPS but now I have a 'problem' with AIDA64: With the older unit I could use AIDA64 to monitor the UPS's internal temperature. power load in Watts, etc... For the new UPS, AIDA64 unfortunately does not show this information, only the "basic" information you can normally get with DeviceIoControl (Runtime, Charge, Serial Number, etc). The new UPS is connected to the PC (Windows 10) via USB, exactly like the old one. APC PowerChute is not installed since their drivers replace the n
  7. Ok, after a restart I noticed I lost the PCH and VRM temperatures I was also monitoring. Makes sense, I guess, and it's not a biggie. One question out of curiosity, though: with EC polling enabled, LatencyMon reports nvlddmkm.sys as the driver with highest reported DPC routine execution time (which does not happen when EC polling is disabled in Aida). Why nVidia's driver? Does the latency go sky high due to a conflict between nVidia's Kernel mode driver and Aida64 (e.g.; both polling the same thing at the same time)? If so, who is doing it wrong (or is it Asus fault)? Also, any
  8. Well, solved it by disabling EC (Embedded Controller) polling in the Stability page of Preferences after doing a search in the forums for latency issues. I don't think I lost any of the sensors I was actually using.
  9. Just to add: I tried disabling items in the OSD one by one while I monitored latency using LatencyMon. Eventually I removed all items leaving only the date but it didn't help. Doesn't Aida64 automatically stop monitoring the sensors that are not selected, or does that require closing the Preferences window first (I was removing the items one by one and then clicking Apply)? Otherwise, the only thing that seems to work is hiding the OSD or exiting Aida64.
  10. Hey Fiery! Not sure if this issue belongs here, but after installing the latest Windows 10 update (KB4517389 & KB4524100) I started noticing a general 'sluggishness' of the system (an Intel 9900K @5Ghz with an Nvidia 2080TI GPU and an Asus Formula XI Maximus motherboard) plus occasional video stutter and audio drop outs. This prompted me to run LatencyMon which showed me the system was running in the red almost constantly (3000 - 5000us + interrupt to process latency). The culprits seemed to be dxgkrnl.sys (highest reported ISR routine execution time) and the Nvidia Windows Kerne
  11. Thanks, Fiery! One last thing: AIDA64 seems to be under-reporting the temperature for my Crucial MX500 1TB SATA SSD (CT1000MX500SSD1). For instance, it currently reports 23ºC which is impossible since ambient temperature is 26ºC. Downloaded Crucial's own Storage Executive to figure this out and there the temperature is reported as a more believable (considering the drive has been idle) 28ºC - so there seems to be a -5ºC offset between real temperature and what AIDA64 is reporting. If it helps, in the AIDA64 SMART values page, C2 Enclosure Temperature currently has a Value
  12. Alas, it seems you were right, Fiery. I didn't explicitly set any of the drives to sleep (I had the option to 'Turn off hard disks' set to 'Never' in Power Options) but it seems there were indeed other power saving 'tricks' (as you very well call them) afoot. Setting PCI Express -> Link State Power Management to Off solved the problem of my M2 and NVMe PCIe drives disappearing. However, the Crucial SATA SSD still disappears from the list from time to time and, unlike what I had previously stated above (sorry) browsing it in My Computer *does* bring it back to life in the OSD,
  13. Hmm... none of the drives are set to sleep when not in use, and they remain available if I go to 'My Computer' and browse through them (and still entries with temps for that drive are not displayed in AIDA64). Anyway, I'll try to find a 'trigger' for some of the drives disappearing from the OSD, this is a brand new Windows 10 system and I am still getting used to it. As for the drive label mix-ups, you could perhaps solve the problem by internally storing the original drive name (as well as the edited name) in each entry in the list. When AIDA64 re-enumerates the drives, the 'hidden' orig
  14. Ok, something else I *just* noticed: If I run HWINFO64, *all* the missing drive temperatures return immediately to the AIDA64 OSD right after HWINFO64 initializes (it says 'flushing buffers' on the splash screen just before this).
×
×
  • Create New...