JcRabbit

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.

Wow. That is far more than I ever expected. Thanks, Fiery.

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 the software must support it in order to get the extended information. Since you don't, there is nothing to do (unless you want to look into it in the future to fully support APC SMT series of Smart UPSs). No idea why APC are no longer also passing the information via the HID Smart Battery API as they did in the previous models (or if that can even be done while also using Modbus), guess I will have to pop that question on their own forums. See here: http://www.apcupsd.org/manual/#modbus-driver

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!

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

Obi Wan?

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 normal Windows HID battery drivers. If I connect the old SUA2200I, I can see the power load, temperature, for that unit as I could before, but when I connect the new SMT2200IC that information is absent - could this be an 'issue' with AIDA64 and the new APC UPSs, the new UPS not transmitting that information, or both? I searched around a bit (and here I am completely out of my depth) before posting here and managed to find some forum posts with more people complaining about the missing info, but they were all from users using unRAID or APCUPSD under Linux. Apparently they could solve the issue by enabling a communication protocol called ModBus on the UPS itself (which comes disabled by default). Not sure if this has anything to do with the issue given that the UPS is connected via USB on a Windows 10 system and not a serial cable. I never-the-less did try enabling ModBus in the UPS Advanced menu but it apparently made no difference? Also, looking at the User Guide and the settings I have available in the UPS, it seems the UPS itself is missing some ModBus configuration settings? In the UPS I could only find settings to enable/disable ModBus and set the ModBus device ID (currently set to 1), and I don't even know if this has anything to do with AIDA64 not being able to get the required info or not lol. I did try contacting APC/Schneider Electric here in Portugal but the tech I talked to had no idea either. What say you? You are my only hope, Obi Wan.

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 idea why this happens on *some* Asus motherboards but not others (according to you)? The Asus Maximus XI Formula is neither old nor low-end.

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.

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.

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 Kernel Mode Driver nvlddmkm.sys (highest reported DPC routine execution time). I installed the latest Nvidia and Realtek drivers, rebooted, no change. So I started exiting all running monitoring and control software (at first I thought it was Corsair iCue given the recent problems) and the only thing that fixed it was exiting Aida64. I use Aida64 primarily for the OSD, where I display system and hard drive temperatures, fan speeds, voltages, APC UPS stats, etc... I tried un-checking anything related to the GPU (GPU Diode and GPU fan speeds) and restarting Aida64 but that didn't help either. I also run MSI AfterBurner, but exiting has no effect on the high system latency while Aida64 is running nor does it increase latency if I run it without Aida64. I'm not sure if the high latency was present before (might have been) but if it was I didn't notice it as it didn't cause audio dropouts. As I stated above, only started noticing this after the latest Windows 10 update. If I exit Aida64, none of the latency values ever go above 250 us (usually fluctuate between 30-110us). Same thing if I hide the OSD in the Aida64 tray icon, of course. Running Aida64 Extreme v6.10.5200 build date 23/09/2019. Any ideas which sensors might be causing this and why? Anything you want me to try?

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 of 77, a Worst of 50 (50ºC is also the highest lifetime temp the drive experienced according to Storage Executive) and a Data value of 23. Intel Drive Toolbox reports for C2 Normalized as 77 and Raw shows 214748364823 (?)

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, which proves the cause is indeed some power saving measure. Problem is, since it is a SATA SSD I have no idea what setting can be causing this on Windows 10, or even if it is a 'feature' of the drive itself (I don't think so since it didn't happen on my previous Windows 7 system). Any ideas?

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' original name would allow it to know if it's trying to assign the new drive to the wrong entry (i.e.; new drive name and entry's original drive name do not match). Also, don't drives have unique hardware IDs? If so, those could be used instead. Hope I am making some sense here.

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

Hi Fiery! :) I'm running AIDA64 Extreme v5.99.4900 on a brand new system with the following specs: Intel 9900K, 32GB RAM, Asus ROG Maximus Formula XI BIOS 506, Intel Optane 905p 960GB NVMe connected to the PCH, Samsung 970 EVO 2TB connected to the M2 slot, Crucial MX500 1TB SATA SSD connected to SATA port 3, WD Blue 4TB connected to SATA port 4, two external WD My Book 3TB connected via USB 3.x. I'm using the OSD to display various stats on my secondary monitor, including drive temperatures. What seems to be happening is that randomly and from time to time some of the drives disappear from the list in the OSD. It can be ANY of the drives, or several at once (for instance, right now one of the external WD HDDs does not show on the list even after restarting AIDA64, although the other does - both drives remain connected and accessible from My Computer). This is made worse by another issue with the OSD, this one going back several years: if you edit the name of one of the drives to make it shorter (e.g.; change 'CT1000MX500SSD1' to 'Crucial MX500') when the drives 'return' they now occupy the wrong 'slots' (for instance, what had previously been the selected entry for CT1000MX500SSD1, which was edited to display 'Crucial MX500', is now displaying the temperature of the Optane drive, but, of course, still under the 'Crucial MX500' label). To be clear, this and the drives randomly disappearing are separate problems - I really wish you could fix the latter though, as it is really confusing, perhaps by associating a drive's unique hardware ID to each 'slot' in the OSD so they can be properly re-assigned when the drive is detected again). Also, are any other applications known to conflict with AIDA64's reading of the sensors? I'm also running Core Temp 1.13 and ASUS GPU Tweak II Monitor.