It is currently April 24th, 2024, 11:47 pm

Usage Monitor IO from just one Drive

Get help with creating, editing & fixing problems with skins
rthrns
Posts: 2
Joined: January 24th, 2019, 3:56 pm

Usage Monitor IO from just one Drive

Post by rthrns »

Hello I am a newbie to skin creation. I am making a skin to report disk space usage and Read/Write activity. from what I understand I should be using the Usage Monitor plugin to do this. In the documentation it says that IOREAD and IOWRITE return b/s from all disks is it possible to set it to read only one disk? I have attached the full .ini file. Open to constructive criticism about any of the code. Thank you for your time

Code: Select all

[MeasureReadDiskC]
Alias=IOREAD
Measure=Plugin
Plugin=UsageMonitor

[MeasureWriteDiskC]
Alias=IOREAD
Measure=Plugin
Plugin=UsageMonitor

[MeterReadDiskC]
AntiAlias=1
Meter=Histogram
MeasureName=MeasureReadDiskC
MeasureName2=MeasureWriteDiskC
UpdateDivider=0
W=210
H=60
X=8
Y=0r
You do not have the required permissions to view the files attached to this post.
Last edited by rthrns on December 24th, 2019, 6:54 am, edited 1 time in total.
mak_kawa
Posts: 908
Joined: December 30th, 2015, 9:47 am

Re: Usage Monitor IO from just one Drive

Post by mak_kawa »

For C drive, something like this;

Code: Select all

[MeasureReadDiskC]
Measure=Plugin
Plugin=UsageMonitor
Category=LogicalDisk
Counter=Disk Read Bytes/sec
Name=C:

[MeasureWriteDiskC]
Measure=Plugin
Plugin=UsageMonitor
Category=LogicalDisk
Counter=Disk Write Bytes/sec
Name=C:
Alias=IOREAD, IOWRITE is for monitoring access per process.
rthrns
Posts: 2
Joined: January 24th, 2019, 3:56 pm

Re: Usage Monitor IO from just one Drive

Post by rthrns »

Okay thanks a lot. Helps when I don't misunderstand the Docs :)
User avatar
balala
Rainmeter Sage
Posts: 16168
Joined: October 11th, 2010, 6:27 pm
Location: Gheorgheni, Romania

Re: Usage Monitor IO from just one Drive

Post by balala »

Besides mak_kawa's reply, note one more: Update=250 in the [Rainmeter] section means four updates per second (one update per 250 milliseconds). DefaultUpdateDivider=240 in the same [Rainmeter] section means that every measure or meter which has no other UpdateDivider set, is updated once per 250 x 240 = 60,000 milliseconds = 60 seconds = 1 minute. Are you sure? This is a too long update period.
I'd probably use DefaultUpdateDivider=4, to get the measures and meters updated once per second, or even better, I'd completely renounce to DefaultUpdateDivider and would set the Update to the default value Update=1000. At least if there isn't something I skipped.
User avatar
Mor3bane
Posts: 943
Joined: May 7th, 2016, 7:32 am

Re: Usage Monitor IO from just one Drive

Post by Mor3bane »

balala wrote: December 24th, 2019, 3:13 pm Besides mak_kawa's reply, note one more: Update=250 in the [Rainmeter] section means four updates per second (one update per 250 milliseconds). DefaultUpdateDivider=240 in the same [Rainmeter] section means that every measure or meter which has no other UpdateDivider set, is updated once per 250 x 240 = 60,000 milliseconds = 60 seconds = 1 minute. Are you sure? This is a too long update period.
I'd probably use DefaultUpdateDivider=4, to get the measures and meters updated once per second, or even better, I'd completely renounce to DefaultUpdateDivider and would set the Update to the default value Update=1000. At least if there isn't something I skipped.
for clocks and timers that are based on a time measure, i set the whole skin to update=990 the timer will not timeout due to sys checks or other skins refreshing causing a slight delay and the skin missing potentially an entire 1000 ms - there would still be a rate of attrition but if the bogging down did occur randomly in relation to processor lag it would not be frequently enough to actually rate as a delay.
My DevArt Gallery

There are many ways to be different - there is only one way to be yourself - be amazing at it

The law of averages says what it means; even if you get everything right, you will get something wrong. Therefore; self managing error trapping initiates another set of averages - amongst the errors, some of them will not be errors, instead those instances will appear to be "luck". One cannot complain of the 'appearance' of 'infinite regress of causation', even if it does not have a predictable pattern, only that it requires luck to achieve.