It is currently March 28th, 2024, 12:22 pm

missing feature in UsageMonitor plugin compared to PerfMon

Report bugs with the Rainmeter application and suggest features.
Post Reply
ronzino
Posts: 22
Joined: June 4th, 2020, 4:41 pm

missing feature in UsageMonitor plugin compared to PerfMon

Post by ronzino »

It seems to me that UsageMonitor has a missing feature compared to PerfMon.

From UsageMonitor Documentation:

"A note on performance [...]

The plugin is then gathering information for that Category, once a second, and is not dependent on, nor reacts to, any setting for Update on the skin, or UpdateDivider on the measure"


The "Once a Second" is quite limiting as well as making it indipendant from skin update.
Due too this I still prefere PerfMon.

Whould be possible to add to UsageMonitor the possibility to take the measure at a custom speed or at least at skin scan time or update or update divider ?

thanks for your help
User avatar
Yincognito
Rainmeter Sage
Posts: 7017
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: missing feature in UsageMonitor plugin compared to PerfMon

Post by Yincognito »

ronzino wrote: June 6th, 2022, 1:14 am It seems to me that UsageMonitor has a missing feature compared to PerfMon.

From UsageMonitor Documentation:

"A note on performance [...]

The plugin is then gathering information for that Category, once a second, and is not dependent on, nor reacts to, any setting for Update on the skin, or UpdateDivider on the measure"


The "Once a Second" is quite limiting as well as making it indipendant from skin update.
Due too this I still prefere PerfMon.

Whould be possible to add to UsageMonitor the possibility to take the measure at a custom speed or at least at skin scan time or update or update divider ?

thanks for your help
Until the developers may or may not answer this, I'll share my take on it, if you're ok with it. The UsageMonitor plugin is not limiting at all - you can still set the Update and UpdateDividers on the skin or the relevant measures just like for everything else - it's just that the data from the plugin doesn't have a "granularity" of less than 1 second, i.e. it doesn't "collect" data more often than that (but you CAN display it at any rate you want).

This is actually the standard behavior in Windows, because if you run PerfMon.msc on your system, you'll see that the values don't "refresh" more often than once every second either. Collecting such info on a higher frequency kind of defeats the purpose of it as well, since you'd want to have an idea about performance related stuff and not flood the system with requests for that info (which has the potential to decrease the "normal" performance you want it measured in the first place, if it's done too often).

That being said, this is a very small price to pay for the overall performance and efficiency of the plugin. If you ask me, I'd have more of a problem with discarding the "0" values like UsageMonitor is doing, than the fact that it doesn't get data at a rate below 1 second, but even that is acceptable in the end. Think about it, where would you need to get the data more often than once a second anyway? I can't think of a critical situation where one would need that... :confused:
User avatar
Brian
Developer
Posts: 2673
Joined: November 24th, 2011, 1:42 am
Location: Utah

Re: missing feature in UsageMonitor plugin compared to PerfMon

Post by Brian »

Yincognito is correct on this. Gathering performance monitor values is a relatively expensive operation and can take a lot of resources when rapidly querying the values from Windows. Running the queries in a separate thread drastically reduces these resources and doesn't slow Rainmeter down when waiting for Windows to return the values.

-Brian
ronzino
Posts: 22
Joined: June 4th, 2020, 4:41 pm

Re: missing feature in UsageMonitor plugin compared to PerfMon

Post by ronzino »

You are right, sampling with an update rate of the skin less then one second a measure sampled at 1hz is no sense.

But there are a lot of case where you need to go below 1hz sampling for example

FFT or vumeter on audio channels
Disk activity monitoring (the good old blinking led)
Time frame of gpu
Cpu core usage or frequency just to have smooth bar transition (over sampling and then averaging)
User avatar
Yincognito
Rainmeter Sage
Posts: 7017
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: missing feature in UsageMonitor plugin compared to PerfMon

Post by Yincognito »

ronzino wrote: June 7th, 2022, 9:33 am You are right, sampling with an update rate of the skin less then one second a measure sampled at 1hz is no sense.

But there are a lot of case where you need to go below 1hz sampling for example

FFT or vumeter on audio channels
Disk activity monitoring (the good old blinking led)
Time frame of gpu
Cpu core usage or frequency just to have smooth bar transition (over sampling and then averaging)
Yeah, well, the thing is that data collection once a second is done not per measure, not per skin, but per Rainmeter instance. So, you can't trick it to enable and trigger a measure at an under 1 second interval compared to another, or use two or more skins to get data at different times during a second.

Since there's no "proper" way (if there's any, to start with) to have two Rainmeters run at the same time on the same machine, we could scrap the perfection requirement from the task (even though I personally love things to be perfect, not to mention I do believe perfection exists and it's possible) and just focus on making it functional, assuming you really really want to do it this way. The code below will provide a basic linear interpolation of what "could" be the CPU usage if the "transition" from one measured value to the one done a second later would happen at a constant rate (a more complex interpolation like a polynomial or a spline one would be appropriate, but this should be enough for demonstration purposes). You can set the Fast and Slow update rates higher to better see what's going on, say 1000 and 10000 for example. The CPUInterpolation measure computes the interpolation between CPUPrev measured a second or more ago and CPULast measured during the "current" second, according to how many UpdatesForSecond passed from the UpdatesPerSecond total ... well, technically it's the amount of Fast updates for and per Slow updates if you reference to something different than one second:

Code: Select all

[Variables]
FastUpdate=25
SlowUpdate=1000
UpdatesPerSecond=(#SlowUpdate#/#FastUpdate#)
UpdatesForSecond=0
CPUPrev=0

[Rainmeter]
Update=#FastUpdate#
DynamicWindowSize=1
AccurateText=1
BackgroundMode=2
SolidColor=47,47,47,255

---Measures---

[CPULast]
Measure=Plugin
Plugin=UsageMonitor
Alias=CPU
Index=0
MinValue=0
MaxValue=100
UpdateDivider=#UpdatesPerSecond#
DynamicVariables=1

[CPUInterpolation]
Measure=Calc
Formula=([#CPUPrev]+[#UpdatesForSecond]*(CPULast-[#CPUPrev])/[#UpdatesPerSecond])
MinValue=0
MaxValue=100
OnUpdateAction=[!SetVariable UpdatesForSecond (([#UpdatesForSecond]+1)%[#UpdatesPerSecond])][!SetVariable CPUPrev ([#UpdatesForSecond]=0?[CPULast:]:[#CPUPrev])]
DynamicVariables=1

---Meters---

[Text]
Meter=String
FontFace=Consolas
FontColor=255,255,255,255
Padding=5,5,5,5
FontSize=16
AntiAlias=1
MeasureName=CPUInterpolation
Text=Prev: [#CPUPrev]#CRLF#Step: [#UpdatesForSecond]#CRLF#ICPU: %1#CRLF#Last: [CPULast:5]
NumOfDecimals=5
DynamicVariables=1

[Lines]
Meter=Line
MeasureName=CPULast
MeasureName2=CPUInterpolation
Y=10R
W=[Text:W]
H=100
LineCount=2
LineColor=0,255,0,255
LineColor2=255,0,0,255
SolidColor=0,0,0,255
AutoScale=1
AntiAlias=1
DynamicVariables=1
I added a Line meter to better illustrate the effect (green is the once per second data, red is the interpolated one):
UsageMonitor Interpolation.jpg
The problem with this is that although it's functional and achieves the purpose of providing data at intervals lower than 1 second ... the values are linear approximates of the usage from 1 second earlier. This is unavoidable, as you'd need to know both the T0 and T1 (where T is time) values in order to compute the interpolation, and since the T1 value can only be for the "current second" (because you can't know values from the future, obviously), the T0 value must be from a second earlier.

Even if you're not ok with the approach, that's the best you can do. Who knows, maybe it can give you some other ideas.
ronzino
Posts: 22
Joined: June 4th, 2020, 4:41 pm

Re: missing feature in UsageMonitor plugin compared to PerfMon

Post by ronzino »

The interpolation part of your message is clear to me in the theory behind and in practical linear implementation and polynomial interpolation or other functions one like log or exp.

Instead this is not clear, I did not get the point. sorry

"Yeah, well, the thing is that data collection once a second is done not per measure, not per skin, but per Rainmeter instance. So, you can't trick it to enable and trigger a measure at an under 1 second interval compared to another, or use two or more skins to get data at different times during a second."

I guess, but I am not so sure, are you speaking about synchronization of the sampling rate of different skin and measure or even different rainmeter instances?

If it is what you are speaking about, it is clear. But we are speaking about rainmeter a wonderful but free software with different purposes, it is not a real time operating system with synchronization mechanics.

Going back more in topic and resuming, usage monitor samples at 1hz as windows performance monitor does, as it is its data source and win monitor has 1hz as minimum sampling frequency.

But now my question is.... At which sampling freq PerfMon works and from where it gathers the data?

Let me guess..... 😝 I guess that PerfMon sampling is equal to skin update rate, BUT its data source is PerfMon (max 1hz sampling). So if I set update in rainmeter =250 it will collect several zeros when it samples an empty measured value buffer. Is it correct?
User avatar
Yincognito
Rainmeter Sage
Posts: 7017
Joined: February 27th, 2015, 2:38 pm
Location: Terra Yincognita

Re: missing feature in UsageMonitor plugin compared to PerfMon

Post by Yincognito »

ronzino wrote: June 7th, 2022, 8:47 pmInstead this is not clear, I did not get the point. sorry

"Yeah, well, the thing is that data collection once a second is done not per measure, not per skin, but per Rainmeter instance. So, you can't trick it to enable and trigger a measure at an under 1 second interval compared to another, or use two or more skins to get data at different times during a second."
Hmm ... as a matter of fact, I had sample skins built for each of those cases (i.e. per measure and per skin attempts to get data at an under 1 second rate, demonstrating that it can't be truly done those ways), but gave up on posting those earlier, since I thought it was too long and convoluted and more or less pointless since I could just write the conclusion instead.

In my per measure example skin, I had 2 UsageMonitor CPU measures, initially disabled, but each of them otherwise set to update once every second, and another dummy Calc measure updated each 500 ms that enabled the other 2 with a 500 ms interval or "delay" between them - in effect achieving an general 500 ms update rate (or hypothetical data collection, if you like) between different measures that were still individually updated once a second. It made no difference, of course, since even though measure 1 got the data at T0=500ms, measure 2 at T1=1000ms, measure 1 again at T2=1500ms, measure 2 again at T3=2000ms and so on, the values were the same for each "second interval" (i.e. values for T0 and T1 were the same, for T2 and T3 the same, and so on).

In my per skin examples, I simply had two basic skins, each with an UsageMonitor CPU measure updated once a second, but I manually loaded or refreshed the skins with a similar "delay" between them. This time, the displayed values were indeed different at a singular moment in time, but the 2nd loaded / refreshed skin just re-collected the same values as the first, only offset in time compared to the 1st. So, it was like 1.5% at T0 for skin 1, 3.2% at T1 for skin 1, 2.7% at T2 for skin 1, yet the delayed same 1.5% at T1 for skin 2, 3.2% at T2 for skin 2 and so on. In other words, not a true under 1 second data collection either.

Which is why that process brought me to the interpolation approach, which achieves the under 1 second data presentation, but with the considerable drawback that the values are for the "previous second interval", so to speak.
ronzino wrote: June 7th, 2022, 8:47 pmBut now my question is.... At which sampling freq PerfMon works and from where it gathers the data?

Let me guess..... 😝 I guess that PerfMon sampling is equal to skin update rate, BUT its data source is PerfMon (max 1hz sampling). So if I set update in rainmeter =250 it will collect several zeros when it samples an empty measured value buffer. Is it correct?
To be honest, I didn't use the PerfMon plugin much. Before UsageMonitor I used a plugin called NomFerp (notice the name being an anagram of the standard plugin at that time) since it had more useful features, so I don't know exactly what the PerfMon plugin does behind the scenes (though its source code can be examined on Rainmeter's GitHub page by anyone). My guess is that the PerfMon plugin grabs the data through related C++ functions / methods within Rainmeter itself (which is why setting the update rates has an actual effect) without necessarily relying on Windows Performance Monitor exposing the values the "standard" way, while UsageMonitor runs in a separate thread from Rainmeter that is updated based on Windows Performance Monitor exposing values at a fixed 1 second interval over which the main Rainmeter thread has no control over, other than triggering the starting and stopping the plugin at Rainmeter or measure run or close. Also, I read somewhere that in the past aka till Windows 7, Windows Performance Monitor (aka perfmon.msc or perfmon.exe) had the ability to sample data at less than 1 second interval, an ability which has in the meantime been removed in favor of the current way of dealing with this now. I'm not sure if the latter had an impact on the way Rainmeter does things, especially if the PerfMon plugin works the same on Win 10 and up, but maybe it played a part in the decision to deprecate the plugin, other than the obvious performance and stability related improvements in UsageMonitor. :???:
Post Reply