[Bug?] UsageMonitor plugin error

[Yincognito]

Try watching it in task manager and see if the same rise in CPU when opening other programs in there, I will be curious to know the results

I would also be curious what the value of this measure is relative to what it is normally (This should normally be 100 * CPUThreadCount aka 400ish on your machine)

Code: Select all

[TopCPUTotalReal]
Measure=Plugin
Plugin=UsageMonitor
Alias=CPU
Rollup=0
Percent=0
Name=_Total

The values from Task Manager and my UsageMonitor Rainmeter skin are more or less similar (give or take, considering the different times of measurements, when it comes to milliseconds). As for the measure and the ThreadsCount:

ThreadsCount.jpg

I'll begin testing your new version in a moment.

[tjhrulz]

The values from Task Manager and my UsageMonitor Rainmeter skin are more or less similar (give or take, considering the different times of measurements, when it comes to milliseconds). As for the measure and the ThreadsCount:
ThreadsCount.jpg

I'll begin testing your new version in a moment.

Okay then, I would call that increase then just an oddity of scheduling tasks on modern multicore systems. If you ever see it increase in the future more than what task manager's detail pane has and [TopCPUTotalReal] is less than 400 that is the cause

[Yincognito]

Thanks for the quick response, that makes me only want to know more since I have yet to encounter it while in a debugger, here is another version that outputs a little more info when it happens.

It shows now:

Code: Select all

This is not an actual error, if this happens let tjhrulz know this: 2472337504480MS_UsageMonitor_ProcessName4 (MYiniMeter\Processes\Processes.ini - [MS_UsageMonitor_ProcessName4])

and:

Code: Select all

Extra Info:  : 0 (MYiniMeter\Processes\Processes.ini - [MS_UsageMonitor_ProcessName2])

I can post the needed elements for the skin, if you want me to, by the way.

EDIT: It began showing different Extra Infos, for various programs in memory, when I unloaded the other skins in the suite and just let my Toggler and Processes skin - I think I'll enable Log To File and Debug Mode so I don't spam screenshots here...

UsageMonitor - Test 01.jpg

[Yincognito]

Some additional info...

The current Log:

Rainmeter.log

My Processes skin and all it dependencies (it's normally part of my suite):

aMYiniMeter_1.4.0.rmskin

EDIT: Also, as soon as I paused the "walkthrough" all the 4 aliases I display in my skin and I set it to the CPU usage (I can do that via right mouse click on the white "title" in the skin - the one showing the custom tooltip skin), the messages from your plugin stopped as well, so it's most likely related to dynamically setting the aliases once every second.

[tjhrulz]

Some additional info...

The current Log:
Rainmeter.log
My Processes skin and all it dependencies (it's normally part of my suite):
aMYiniMeter_1.4.0.rmskin

EDIT: Also, as soon as I paused the "walkthrough" all the 4 aliases I display in my skin and I set it to the CPU usage (I can do that via right mouse click on the white "title" in the skin - the one showing the custom tooltip skin), the messages from your plugin stopped as well, so it's most likely related to dynamically setting the aliases once every second.

Got it, that is totally fine as that code just exists to handle when I think something is using DV=1 or has had a !SetOption applied to it. I just wanted to make sure that the code I wrote was working successfully which it would seem it is.

Knowing that for anybody else that is downloading a test version now or would like one with that debugging code removed here is a new version with that debug log removed. So now we are back to letting me know if you see ANY error logs come up from normal use.

[Yincognito]

Got it, that is totally fine as that code just exists to handle when I think something is using DV=1. I just wanted to make sure that the code I wrote was working successfully which it would seem it is.

Knowing that for anybody else that is downloading a test version now or would like one with that debugging code removed here is a new version with that debug log removed. So now we are back to letting me know if you see ANY error logs come up from normal use.

Aham. So now I download the new posted version and just let you know if any errors show up. Got it.

[Yincognito]

By the way, is it normal to have those UsageMonitor values at 0 for a couple of moments when loading Rainmeter? I don't recall it happening before - although I could be very well mistaken, since the skin stayed a for long time showing the static value of CPU usage before these tests (the walkthrough the aliases is more of a feature than something I personally use). I do remember the skin showing numbers like 1 or 2 (as the name of the top process) at Rainmeter load though, in the past, so it might be just a part of the normal "initialization" process...

P.S. No errors so far.

EDIT: One other thing I wanted to ask: the GPU alias is always 0 when dynamically walking through aliases once every second, and when I pause it to show the GPU top processes, only Rainmeter with a little more than 1% GPU usage is shown. Is this normal? Could it be because my GPU card (AMD HD 7610M, 1GB DDR3) doesn't support hardware encoding and thus less programs use the GPU? Even so, Chrome should definitely use it and be quite high on it, since it's taking up quite a bit of CPU as well when it starts.

[tjhrulz]

By the way, is it normal to have those UsageMonitor values at 0 for a couple of moments when loading Rainmeter? I don't recall it happening before - although I could be very well mistaken, since the skin stayed a for long time showing the static value of CPU usage before these tests (the walkthrough the aliases is more of a feature than something I personally use). I do remember the skin showing numbers like 1 or 2 (as the name of the top process) at Rainmeter load though, in the past, so it might be just a part of the normal "initialization" process...

P.S. No errors so far.

EDIT: One other thing I wanted to ask: the GPU alias is always 0 when dynamically walking through aliases once every second, and when I pause it to show the GPU top processes, only Rainmeter with a little more than 1% GPU usage is shown. Is this normal? Could it be because my GPU card (AMD HD 7610M, 1GB DDR3) doesn't support hardware encoding and thus less programs use the GPU? Even so, Chrome should definitely use it and be quite high on it, since it's taking up quite a bit of CPU as well when it starts.

Yes that is normal, to prevent Rainmeter from being blocked (aka doing nothing) while reading performance counters I just give Rainmeter empty data until the counters have updated, then on the next update of your skin it will read those counters now that they have been set up. These counters take a very long period of time to set up and update (EACH counter has an unavoidable ~100ms hit on EVERY update even on a decent CPU). So if no other skin is currently also reading that counter then it is going to take time to get everything set up and reading back data, this takes even longer to happen with GPU aliases due to us also needing to set up another counter so that we can translate the PIDs and Graphics Engine data into a human readable name. This is likely why that one is giving you issue due to it being a separate performance counter that has more work to set it up every time. Also GPU usage in from that data can seem odd like that, for example you will find even if you are GPU bound in a game that it likely will never hit 100% load. This is because frequently there are other things holding your FPS back besides raw compute such as memory transfer speed bottlenecks as well as some of that GPU cost that programs have is hidden in system apps that are frequently in blocklists like DWM, System, csrss, and several others that escape me at the moment.

I would recommend maybe the instead of scrolling through aliases on one measure make a different measure for each alias you want to use and scroll through the measure that the meter reads from. This should avoid you needing to use DV=1 and you data will also likely be more recent than what you have now. This also may fix your GPU stuff being 0 and likely will have a more consistent if not also a little bit better performance than before as I built usage monitor to share as much CPU cost as possible between measures, even if they are in different skins so having multiple measure is not an issue

[Yincognito]

Yes that is normal...

Oh ok, that explains it - thanks for letting me know.

I would recommend maybe the instead of scrolling through aliases on one measure make a different measure for each alias you want to use and scroll through the measure that the meter reads from. This should avoid you needing to use DV=1 and you data will also likely be more recent than what you have now. This also may fix your GPU stuff being 0 and likely will have a more consistent if not also a little bit better performance than before as I built usage monitor to share as much CPU cost as possible between measures, even if they are in different skins so having multiple measure is not an issue

I slightly disagree here. I employed reusable measures intentionally, to both make the code more compact (it does wonders in my Weather skin, for example, where instead of hundreds of measures I only have around 50 that get reused by means of DV and scrolling, and this is true for most of my other skins in the suite as well, bar the CPU skin, where I have to have measures for each logical CPU as those values are all displayed at the same time, unlike in the other cases) and save resources by having a reduced number of measures. It's good to know that you designed your plugin to handle efficiently the multiple measure scenario (didn't know that), so this could be an exception from the rule, but I'd have to weigh in the pros and cons of doing that in just one skin. I do put an emphasis on performance and efficiency, but not so much of having some small delay in measurements - as long as they're accurate and low on resources (which they are, bar the other programs being active scenario I talked about earlier).

I doubt your suggestion would fix the GPU stuff being 0 (it's not that it's 0, it's the fact that other than Rainmeter itself, the other programs never appear), since that happens even when there is no scrolling and the automatic walkthrough the aliases is paused. I think I have tested this in another skin just to make sure, and it was the same - that's why I mentioned that maybe some particularity of the GPU is the "issue" here. Ah, just recalled that I also looked in PerfMon itself and likewise, only Rainmeter was there consuming GPU.

[tjhrulz]

Oh ok, that explains it - thanks for letting me know.


I slightly disagree here. I employed reusable measures intentionally, to both make the code more compact (it does wonders in my Weather skin, for example, where instead of hundreds of measures I only have around 50 that get reused by means of DV and scrolling, and this is true for most of my other skins in the suite as well, bar the CPU skin, where I have to have measures for each logical CPU as those values are all displayed at the same time, unlike in the other cases) and save resources by having a reduced number of measures. It's good to know that you designed your plugin to handle efficiently the multiple measure scenario (didn't know that), so this could be an exception from the rule, but I'd have to weigh in the pros and cons of doing that in just one skin. I do put an emphasis on performance and efficiency, but not so much of having some small delay in measurements - as long as they're accurate and low on resources (which they are, bar the other programs being active scenario I talked about earlier).

I doubt your suggestion would fix the GPU stuff being 0 (it's not that it's 0, it's the fact that other than Rainmeter itself, the other programs never appear), since that happens even when there is no scrolling and the automatic walkthrough the aliases is paused. I think I have tested this in another skin just to make sure, and it was the same - that's why I mentioned that maybe some particularity of the GPU is the "issue" here. Ah, just recalled that I also looked in PerfMon itself and likewise, only Rainmeter was there consuming GPU.

Ah I misunderstood you, the way you said that I thought you were saying that it was broken only when doing the scrolling, if it is working the same with and without scrolling then you are good to go and there is no need to change anything.

But yeah I would say this plugin is the exception to the rule and definitely that recommendation would not be true for just about any other plugin. I just know how poorly people used the plugins that came before UsageMonitor and if I was going to build a threading system that would take the updates off the UI thread for Rainmeter to prevent the stutter that happened with those other plugins I figured I might as well build a monolithic system that made sure as much resources as possible were shared so that I effectively automated the parent child process that people were supposed to do (But did not) with those previous plugins and applied it even across skins which was not possible before causing significant performance gains