Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
MSI X399 sensors performance
Seems there is a pretty big hit to performance when accessing sensors on this board, no matter what I'm monitoring. If you want, here is debug file and report.

Attached Files
.htm   USER-PC.HTM (Size: 261.26 KB / Downloads: 4)
.dbg   HWiNFO64.DBG (Size: 1.98 MB / Downloads: 1)
Can you please be more specific what kind of performance loss do you experience ?
Have you tried to disable sensors one by one to determine which of them is causing this ?
There is no performance loss of the system as a whole. Just more like ... It's something like the ASUS EC where it was recommended to disable it to increase the performance of HWINFO (faster polling speed). Just trying an extreme example like 100ms poll rate. If I disable every sensor except the "CPU [#0]: AMD Ryzen Threadripper 1950X" group, or disable every sensor except the "GPU [#0]: NVIDIA GeForce GTX 1080 Ti: " group, or have all groups enabled, it's about the same poll speed (250-300ms). It seems like doing any polling of sensors at all adds about 150-200ms of time per poll interval. Maybe this is just an effect of the threadripper platform?
You can enable showing of the "Profiling Time" column in HWiNFO sensors, then you see exactly how much which sensor takes to read out.
This is very helpful to diagnose such cases. Please let me know the results.
Ah, I didn't know that was available! I enabled it and every column shows 0 ms time except for 1 or 2 GPU sensors every now and then (15 or 16ms, otherwise 0). Maybe threadripper is just 'slow'?
I don't think that's because of Threadripper. If all sensors show such low latency, it must be something else - perhaps the GUI or if you use some addons to poll sensors from HWiNFO. I assume you don't use Remote Sensor Monitoring.
I don't use any addons, just plain jane HWINFO64 sensors that display in the system tray.
Another reason might be if Debug Mode or sensor logging (to a slow drive) is enabled.
Also you might test with the sensors window minimized to exclude GUI being the reason.
Debug not enabled, "Automatic Logging" is not enabled either. I minimized the GUi so only tray is showing. I selected 100ms polling period to exacerbate the issue, heres a GIF video.
Ah yes, you're right. There's one more function that retrieves information from all CPU cores, which isn't included in these profiling times. This must be the reason of the delay - to check status of all cores/threads on the Threadripper requires more time but most probably due to the higher amount of cores.
Quite maybe. CoreTemp doesn't seem to have any polling speed issue though it does give less info too (no power figures), so there is that.
Hm, I have measured the CPU scan on my Threadripper system and here it takes only ~16 ms to scan all cores.
So not sure why it would take so long on yours..
I'm sure you saw the system report so you can at least see what the system is comprised of. If you can think of anything that would cause that, i'd be happy to help
I've reinstalled OS from win8.1 to a fresh Win10 copy. I did run -nothing- for a little bit to see if the perf was better, but it was still about the same, so no sure about that one (still had 'slow' polling speed).

Also, there are 2 VRM sensors, one for something auxiliary (SoC?) which has relatively stable readings, the other probably feeding the CPU cores (output voltage matches), but its readings are extremely unstable and it doesn't always show up in sensors unless hwinfo64 has been running a while (ran it overnight to see it was showing). Correct readins are when output votlage is about 1.48-ish, and temperature ~51C.
Looks like readout from that VRM sensor is often erratic. If the other VRM provides good values and since the readout method used for both is same, I'm not sure what could be causing this. Perhaps some problem with that device or something else in the system causing interference.

Forum Jump:

Users browsing this thread: 1 Guest(s)