Confusion about VDEF total and graph values

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Confusion about VDEF total and graph values

humke
Hi,

I am using rrdtool to store values from my smart meter (electricity and gas). For the gas part I am a bit confused about what is graphed and shown as a total for the graph's period of time.

First, some info about the rrd file I use to store the gas counter values from my meter:

filename = "smartgas.rrd"
rrd_version = "0005"
step = 3600
last_update = 1476359209
header_size = 752
ds[gasconsumed].index = 0
ds[gasconsumed].type = "DCOUNTER"
ds[gasconsumed].minimal_heartbeat = 86400
ds[gasconsumed].min = NaN
ds[gasconsumed].max = NaN
ds[gasconsumed].last_ds = "1182.31"
ds[gasconsumed].value = 0.0000000000e+00
ds[gasconsumed].unknown_sec = 0
rra[0].cf = "LAST"
rra[0].rows = 10980
rra[0].cur_row = 0
rra[0].pdp_per_row = 24
rra[0].xff = 5.0000000000e-01
rra[0].cdp_prep[0].value = 5.5555555556e-05
rra[0].cdp_prep[0].unknown_datapoints = 7
rra[1].cf = "LAST"
rra[1].rows = 8784
rra[1].cur_row = 24
rra[1].pdp_per_row = 1
rra[1].xff = 5.0000000000e-01
rra[1].cdp_prep[0].value = 0.0000000000e+00
rra[1].cdp_prep[0].unknown_datapoints = 0

Here's the code I use to create a graph from this rrd:

sudo rrdtool graph /var/www/html/gaslast.png \
        --start -2d -w 1000 -h 300 -Y -L 8 \
        -t "Afname gas afgelopen 24 uur (LAST mode)" \
                DEF:gascons=$gasrrd:gasconsumed:LAST \
                VDEF:gastot=gascons,TOTAL \
        COMMENT:"                       Total   \n" \
        AREA:gascons#$gasconsareacol:"Afgenomen (m3)" \
        LINE0.8:gascons#$gasconslinecol \
        GPRINT:gastot:"%9.3lf\n" \
        --watermark "Generated `date`"

The $ variables are defined somewhere else and represent actual color codes and the rrd file name.

Here's an example of generated graph:



I was expecting the total value mentioned below the graph to be equal to the sum of all values in the graph. But as you can see it is not (or I misinterpret things). The gas counter value uses 3 decimal places and this counter is in m3 (in the rrdinfo output you only see two decimals because the last decimal is 0). I would expect the y-axis values to be represented in 'm' instead of 'u'. When I add all the graph values myself I get to a total of aprox. 380u m3. This does not match with the presented total of 1.384 m3.

Likely I am misunderstanding some rrdtool concepts here. Could someone enlighten me?

Humke
Reply | Threaded
Open this post in threaded view
|

Re: Confusion about VDEF total and graph values

Alex van den Bogaerdt-5
> Here's the code I use to create a graph from this rrd:
>
>
>
> The $ variables are defined somewhere else and represent actual color
> codes
> and the rrd file name.

Maybe it's just me, but I don't see anything there.


> Here's an example of generated graph:
>
> <http://rrd-mailinglists.937164.n2.nabble.com/file/n7583425/gaslast.png>

> I was expecting the total value mentioned below the graph to be equal to
> the
> sum of all values in the graph. But as you can see it is not (or I

There are no values in the graph. There are rates in the graph.

I focus on the big bars only. I see three of them, somewhere around 182u,
141u and 58u.
These are rates:  {something} per second.
Each bar is valid for an hour.

So, 3600 x 182u + 3600 x 141u + 3600 x 58u
= 3600 x (182u+141u+58u)
= 3600 x 381u
= 1371600u = 1371.600m

The rest is due to the rates I ignored, and perhaps some rounding
differences.

The main thing to remember: you are watching rates, not values.
You are adding surface, not height.


HTH
Alex


_______________________________________________
rrd-users mailing list
[hidden email]
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
Reply | Threaded
Open this post in threaded view
|

Re: Confusion about VDEF total and graph values

humke
Ah yes of course, that just explains it Alex, thanks!

I didn't think this through enough. There's more happening than just calculating the difference between the last two measured values. When graphed that difference is spread out over 3600 seconds (in my case), thus indeed becoming a rate.

I remember reading many times about this rate vs value thing (maybe even on your site). I guess working with GAUGE DST's a lot (which are already a rate) before starting with the gas counter made me forget this important part.

Thanks again!
Reply | Threaded
Open this post in threaded view
|

Re: Confusion about VDEF total and graph values

humke
Actually talking about microcubes of gas per hour sounds kinda cool.

By the way, I am not sure why you don't see the code with the variables. It's there when I lookup the post via the forum solution on oetiker's rrdtool website:

Inline image 1



Groet,
Arjan

On Thu, Oct 13, 2016 at 4:06 PM, humke [via RRD Mailinglists] <[hidden email]> wrote:
Ah yes of course, that just explains it Alex, thanks!

I didn't think this through enough. There's more happening than just calculating the difference between the last two measured values. When graphed that difference is spread out over 3600 seconds (in my case), thus indeed becoming a rate.

I remember reading many times about this rate vs value thing (maybe even on your site). I guess working with GAUGE DST's a lot (which are already a rate) before starting with the gas counter made me forget this important part.

Thanks again!


If you reply to this email, your message will be added to the discussion below:
http://rrd-mailinglists.937164.n2.nabble.com/Confusion-about-VDEF-total-and-graph-values-tp7583425p7583427.html
To unsubscribe from Confusion about VDEF total and graph values, click here.
NAML

Reply | Threaded
Open this post in threaded view
|

Re: Confusion about VDEF total and graph values

Simon Hobson
humke <[hidden email]> wrote:

> By the way, I am not sure why you don't see the code with the variables.
> It's there when I lookup the post via the forum solution on oetiker's
> rrdtool website:

Same here - I see it on the website, but not in the emails I got from the list. My guess is that it got stripped in the plain-text conversion by the mailing list manager.

_______________________________________________
rrd-users mailing list
[hidden email]
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
Reply | Threaded
Open this post in threaded view
|

Re: Confusion about VDEF total and graph values

Alex van den Bogaerdt-5
In reply to this post by humke
> Actually talking about microcubes of gas per hour sounds kinda cool.

That's not what you show in your graph. You show microcubes of gas per
second, at a resolution of one hour.

It's easy enough to change that: just use a CDEF to multiply by 3600. Each
bar will then show the amount per hour.

It is easy to confuse yourself or the occasional other viewer when doing
so, so be careful.  For instance: you should get the VDEF from the
original DEF, not from the CDEF. Or else you would appear to use 3k6 times
the gas you are really using.


By the way: you may want to write down the number from the meter, do the
same 24 hours later, and compare against the graph. If it matches: good.
If not, you need to do some more bug hunting.  Perhaps you already think
of this, perhaps not.



_______________________________________________
rrd-users mailing list
[hidden email]
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
Reply | Threaded
Open this post in threaded view
|

Re: Confusion about VDEF total and graph values

humke
I tried the CDEF to see if this would generate the graph that I initially expected and (of course) it does. As you suggested the total value is still calculated with VDEF.

It would be nice if I could draw vertical lines after each interval from height=rate/value to the x-axis. That way the graph would look more like a histogram which might help making the correct interpretation more easy. I looked at VRULE, but that's not going to help here as far as I can tell.

I already established for myself that the calculated total value matches with what the meter shows at different times. So I am pretty sure everything is ok now. Everytime I checked, the last stored value (as seen in rrdinfo output) also matches with the meter value, so rrdtool is working with the correct values and everything that I think comes out wrong is all just me ;)
To be 100% sure I will do some write-downs of the meter value and create some graphs with the same intervals as the write-downs. Things (the total value) should match then.

The gas meter itself updates in real-time, however the smart meter (from which I get the data) only 'asks' the gas meter once every hour for the counter value at that time. This can't be influenced, so as far as I can tell a step size smaller than 3600 doesn't make sense in this case. Because the smart meter also gives me power data and does so every 10 seconds, I actually read (and store) the gas counter value and power values also at a 10 second interval. Therefor I decided to use the LAST CF for the gas counter. The MAX CF would probably have the same effect since the counter is only going up.


_______________________________________________
rrd-users mailing list
[hidden email]
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users

Reply | Threaded
Open this post in threaded view
|

Re: Confusion about VDEF total and graph values

Bram
You may want to consider splitting the databases.  You can always combine the data for the graph later, if you want.  I take the readings every 10 seconds too, but will populate the gas database only when the timestamp of the gas reading changes.

Bram
Reply | Threaded
Open this post in threaded view
|

Re: Confusion about VDEF total and graph values

Alex van den Bogaerdt-5
In reply to this post by humke
> It would be nice if I could draw vertical lines after each interval from
> height=rate/value to the x-axis. That way the graph would look more like a
> histogram which might help making the correct interpretation more easy. I
> looked at VRULE, but that's not going to help here as far as I can tell.

You mean you want to see the same bars, only reduced in width? In other
words, get smaller bars with gaps inbetween?

If not, stop reading and explain further.




Okay, you're still here. Do get the desired effect, you do want to graph
the portion of the bar at the beginning of each hour, and not the
remainder.  Or maybe half a bar, centered around half of the hour.

One bar per hour, so you need to repeat every hour: time_in_seconds modulo
3600.
You end up with a number 0 <= timeval < 3600.
Then you decide to graph the bar if 'timeval' is inbetween some arbitrary
limits. If it is not, then you graph nothing.

For instance: graph if timeval <1800.  Or graph if  900 <= timeval <= 1800.


First a heads up: the following procedure may not work. If so, we need to
implement a trick. It depends on the internal resolution rrdgraph is
working with.  I will explain after I'm done building the CDEF.



I know what I want but I still look in the manual:
http://oss.oetiker.ch/rrdtool/doc/rrdgraph_rpn.en.html

I see LIMIT, TIME, and % which means modulo. While building the CDEF I
notice I need to compare against unknown and I need to push unknown on the
stack:  IF, UN and UNKN.

if ((time modulo 3600) inbetween 900,1800) return value else return unknown

time modulo 3600:   TIME,3600,%
inbetween 900,1800: 900,1800,LIMIT

You now have some value 900..1800, or unknown.

Test against unknown: UN

You now have true or false, for outside limits, inside limits.
It will also be true when the input value was unknown (meaning: no data
available)

if (true) then return unknown else return value.

we already have true (or false) on the stack. We need to push unknown and
the original value:

UNKN, orig

And then push command 'IF' to select one of these two.

This leads to the following CDEF:

CDEF:newval=TIME,3600,%,900,1800,LIMIT,UN,UNKN,orig,IF

Instead of orig, you could also work with orig x 3600. Just insert
"3600,*," before IF

I showed you how I think it can be done, but I did not test anything.
There will be other ways to reach the same or a similar outcome. You can
alter the limits to alter the resulting bars.

You need to test this CDEF and correct any mistakes I made.



So, what was the problem which may occur?  If rrdtool graph is working
internally with slots of 3600 seconds, then TIME,3600,% will always return
0. This means you can not work with portions of an hour.

The solution is then to include another datasource, one that has a better
resolution, to force rrdtool graph to work with smaller intervals. You
don't really have to display that other data source, you would only
(ab)use it to tweak the inner workings of RRDtool.

There may be other, less resource intensive, ways to accomplish this goal.
And you may not have to do it at all. You figure this out yourself.

I suggest you read the tutorial and especially the part where we generate
alternating background colors. It works in a similar way.


> The gas meter itself updates in real-time, however the smart meter (from
> which I get the data) only 'asks' the gas meter once every hour for the
> counter value at that time. This can't be influenced, so as far as I can
> tell a step size smaller than 3600 doesn't make sense in this case.

Sounds logical to me as well.

If you'd have step sizes smaller than 3600 seconds and measure more often
than every 3600 seconds, you would end up will all gas used during the
last of each step, and zero in the others. Definately not want you want.

> Because
> the smart meter also gives me power data and does so every 10 seconds, I
> actually read (and store) the gas counter value and power values also at a
> 10 second interval. Therefor I decided to use the LAST CF for the gas
> counter. The MAX CF would probably have the same effect since the counter
> is only going up.

No, this is incorrect. You really should study how RRDtool works because
right now you will be in for nasty surprises later on.

Remember what I said: you are working with surfaces, not with width or
height alone.

Suppose later, when everything seems to be working, you will want to
display a graph showing usage for a month?  You cannot show 31 x 24 bars,
so you will use >>>consolidated<<< data.  You will, for instance, combine
24 hours into one 'day' (in UTC time, so 22:00-22:00 during summer,
23:00-23:00 during winter).
You end up with 31 bars where each bar describes a rate during 86400 seconds.

Write down 24 consecutive rates. They will differ during the day.

How do you want to combine these 24 rates into 1 ?

Hint: you do not want the last of these 24 (but you are doing that now:
LAST CF).
Hint: you do not want the highest of these 24 (but that would happen when
using MAX CF).

Once more: surface, not rate.

_______________________________________________
rrd-users mailing list
[hidden email]
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
Reply | Threaded
Open this post in threaded view
|

Re: Confusion about VDEF total and graph values

Simon Hobson
In reply to this post by Bram
Bram <[hidden email]> wrote:

> You may want to consider splitting the databases.

That's a "six of one, half a dozen of the other" choice really. In this case, it's not too likely that you'd be wanting to add or abandon data sources, but I'd probably also use separate files.
The main reason for splitting them would be to allow complete independence of updates. As it is, you have different update periods for the two data sources, that alone says to use separate data files.

_______________________________________________
rrd-users mailing list
[hidden email]
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
Reply | Threaded
Open this post in threaded view
|

Re: Confusion about VDEF total and graph values

humke
In reply to this post by Bram
I am already using three RRD's (three files):

1. power: stores 2 values: power from the grid and power to the grid every 10 secs
2. sun: stores 1 value: power generated by solar panels every minute
3. gas: stores 1 value: stores the hourly updated gas counter value every 10 secs

1 and 3 are updated from the same script that reads the smart meter. I could make the script more intelligent and only have it update the gas rrd when needed (or copy the script and only let it work on the gas part and then run it hourly), but from a functional point of view I don't think it matters. It would help on some I/O, CPU and in the end probably will make my SD Card in the raspberry PI live longer (the rrd file is being allocated in advance  so the gas value will be written at the same location on the SD Card many times per hour in my case, right?). 

Arjan


Groet,
Arjan

On Fri, Oct 14, 2016 at 12:15 PM, Bram [via RRD Mailinglists] <[hidden email]> wrote:
You may want to consider splitting the databases.  You can always combine the data for the graph later, if you want.  I take the readings every 10 seconds too, but will populate the gas database only when the timestamp of the gas reading changes.

Bram


If you reply to this email, your message will be added to the discussion below:
http://rrd-mailinglists.937164.n2.nabble.com/Confusion-about-VDEF-total-and-graph-values-tp7583425p7583432.html
To unsubscribe from Confusion about VDEF total and graph values, click here.
NAML

Reply | Threaded
Open this post in threaded view
|

Re: Confusion about VDEF total and graph values

humke
In reply to this post by Alex van den Bogaerdt-5
Alex van den Bogaerdt-5 wrote
You mean you want to see the same bars, only reduced in width? In other
words, get smaller bars with gaps inbetween?
That would also work visually, but what I had in mind was not to reduce the width, but create the bars by separating them with vertical lines of the correct height.

So, now I will need some time to play around based on your detailed explanation :)

Alex van den Bogaerdt-5 wrote
If you'd have step sizes smaller than 3600 seconds and measure more often
than every 3600 seconds, you would end up will all gas used during the
last of each step, and zero in the others. Definately not want you want.
Wouldn't this actually create the desired bars in a more easy way? I will try...

Alex van den Bogaerdt-5 wrote
Write down 24 consecutive rates. They will differ during the day.

How do you want to combine these 24 rates into 1 ?

Hint: you do not want the last of these 24 (but you are doing that now:
LAST CF).
Hint: you do not want the highest of these 24 (but that would happen when
using MAX CF).

Once more: surface, not rate.
I can see where you are going with this. I want the total surface of 24 bars to be the same as the surface for the 1 bar. So AVERAGE would be the correct CF choice here, because only that CF would give me the same surface.  I will try this.

I could (or maybe even should) still use LAST for the highest resolution (one hour) in this case right? As it's one PDP or are all my 10 second tries to store the value also CF'ed?

I do need to read the tutorials again, because I am getting all these questions about stuff I thought I understood.

humke
Reply | Threaded
Open this post in threaded view
|

Re: Confusion about VDEF total and graph values

Pavel Ruzicka-2
In reply to this post by humke
Hi Arjan,

> but from a functional point of view I don't think it
> matters. It would help on some I/O, CPU and in the end probably will make
> my SD Card in the raspberry PI live longer (the rrd file is being allocated
> in advance  so the gas value will be written at the same location on the SD
> Card many times per hour in my case, right?).

Most of new SD cards use "wear leveling" that if your system will write to
same place on the filesystem that controller in the card wrote data everytime
to another place.
For bigger lifetime it is a good idea to have Flash not full.

Also it is a good idea to use "Industrial grade" SD card which use SLC chips
instead MLC or TLC chips at normal flash cards and have much bigger number of
writes to cells.

Best regards,

Pavel

_______________________________________________
rrd-users mailing list
[hidden email]
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
Reply | Threaded
Open this post in threaded view
|

Re: Confusion about VDEF total and graph values

Simon Hobson
In reply to this post by humke
humke <[hidden email]> wrote:

> I can see where you are going with this. I want the total surface of 24 bars
> to be the same as the surface for the 1 bar. So AVERAGE would be the correct
> CF choice here, because only that CF would give me the same surface.  I will
> try this.

Correct

> I could (or maybe even should) still use LAST for the highest resolution
> (one hour) in this case right? As it's one PDP or are all my 10 second tries
> to store the value also CF'ed?

What is your step size - that has a large impact on what you need t put in and what you get out.

If (for example) your step size is one hour (for the gas), and you ask for data with a resolution of one hour, **AND** you have put in data exactly every hour ON THE HOUR - then you'll get out what you put in (barring rounding errors and conversion from counter to rate).
If you remove the "on the hour" bit of that, then what you get out will be different to what you put in. So say your meter gives you data timestamped at 20 minutes past the hour, each one hour slot within the RRD will comprise 1/3 of one value plus 2/3 of the next value. Ie, to give you a value for the slot from 12 noon to 1pm, it'll use 1/3 of the value from 11:20 to 12:20 plus 2/3 of the value from 12:20 to 13:20 - and you will not see any data (it'll return as NaN) for that slot until the 13:20 data is entered.

Consolidation functions have no effect on this as this is the standard normalisation to map the data you put in to the primary data points (PDPs) defined by your step size.

Updating more often than the step size doesn't really change this - all the interim data is just accumulated up until you pass the next step time and the PDP is complete. So the above example is modified a bit. Assuming that the data actually only changes at 20 minutes past the hour, if you updated (using the same counter value) every minute, the 12:00-13:00 PDP could be completed as soon as 13:00 (if you update "on the minute") or at the latest by 13:01.

This would give you different values though.
Assuming usage was zero beforehand, 3600 units registered in the 12:20 update, and 7200 units registered in the 13:20 update.
Updating hourly with the data timestamp will give usage for 12:00-13:00 of 1.67 units/s (1/3 x 3600 + 2/3 * 7200). If you update every minute on the minute, all the 3600 units would appear to have been used between 12:19 and 12:20 with zero for the other 59 minutes. At 13:00, RRD would "close" the PDP, average the 3600 units across the hour, and arrive at a value of 1 unit/s.

In reality, neither value is right, and neither value is wrong ! You might have been (for example) running the shower (and hence burning plenty of gas) before 12, or after 12, and using nothing at other times; or you might have had the heating on, and burned the same amount of gas at a steady rate during the whole hour - but the meter won't tell you. Just like the example Alex uses in his tutorial - you might have driven slowly for an hour, or driven like a lunatic for part of the time and stopped for a coffee, in either case the odometer will only tell you total distance travelled unless you read and store the values at frequent intervals.


Now, what does the CF do to this ? Actually nothing ! If "a" is a simple number, then min(a)=avg(a)=max(a)=last(a). However, if "a" were a set of numbers 1,2,3,40,4, then min(a)=1, avg(a)=10, max(a)=40, and last(a)=4
In my experience, LAST as a CF is only of use for printing in the legend to show the last value on the graph, or rather, the last value that went into the last CDP shown on the graph. So taking those numbers I just used, you could have a column on the graph (assuming you are using a consolidation of 5 PDPs into one CDP) that's 10 units high, and assuming no larger values, last would show 4.

So if you have a step size of 1, and graph hourly data, the consolidation function used is effectively a null operation - assuming you have a CF consolidating 1 PDP into a CDP !

> I do need to read the tutorials again, because I am getting all these questions about stuff I thought I understood.

To be fair, there's come fairly complicated stuff going on there, it does take some getting your head around.
_______________________________________________
rrd-users mailing list
[hidden email]
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
Reply | Threaded
Open this post in threaded view
|

Re: Confusion about VDEF total and graph values

Alex van den Bogaerdt-5
In reply to this post by humke
> Alex van den Bogaerdt-5 wrote
>> You mean you want to see the same bars, only reduced in width? In other
>> words, get smaller bars with gaps inbetween?
>
> That would also work visually, but what I had in mind was not to reduce
> the
> width, but create the bars by separating them with vertical lines of the
> correct height.

I have difficulty understanding what you describe here.


>> If you'd have step sizes smaller than 3600 seconds and measure more
>> often
>> than every 3600 seconds, you would end up will all gas used during the
>> last of each step, and zero in the others. Definately not want you want.
>
> Wouldn't this actually create the desired bars in a more easy way? I will
> try...

Suppose you have steps of 15 minutes. 3 steps the gas consumption is 0
kuub, then for one step there is a rate, then 3 steps zero again, et
cetera.

When graphing a day, you would graph 96 bars, 72 of them being zero. 24
bars would show all gas consumption but 4 times as high as you would
expect.

This can be corrected with a CDEF, no problem.

But... what happens when you are going to display your data for a week?
For a month?  For a year?  This is where consolidation kicks in. Which
brings us back to the next part:


>> Write down 24 consecutive rates. They will differ during the day.
>>
>> How do you want to combine these 24 rates into 1 ?
>>
>> Hint: you do not want the last of these 24 (but you are doing that now:
>> LAST CF).
>> Hint: you do not want the highest of these 24 (but that would happen
>> when
>> using MAX CF).
>>
>> Once more: surface, not rate.
>
> I can see where you are going with this. I want the total surface of 24
> bars to be the same as the surface for the 1 bar. So AVERAGE would be the
> correct
> CF choice here, because only that CF would give me the same surface.  I
> will try this.

Indeed.

> I could (or maybe even should) still use LAST for the highest resolution
> (one hour) in this case right? As it's one PDP or are all my 10 second
> tries
> to store the value also CF'ed?

Phase one: converting the input number to a rate.

Your step size is 3600. You can update multiple times within this one
step, no problem. The result is still one step.

Normalizing happens here. If/when you update with timestamps which are not
a whole multiple of the step size, this may produce surprising results if
you are unaware of normalizing.

Consolidation did not yet happen, but you do now have a normalized rate.

One update can generate more than one step. This could happen for instance
if you update every two hours. You have two (or more) separate steps with
independent normalized rates.

Next phase: storing the rates in the RRD. This is where consolidating
happens.

If there is only one step, then consolidation is a no-op. First, last,
min, max, they are all the same.

min(2) = max(2) = average(2) = last(2) = 2

The consolidation process is important when more than one step is turned
into one bigger step, e.g. 4 times one hour becomes one time 4 hours.

min(4,0,1,3) = 0
max(4,0,1,3) = 4
average(4,0,1,3) = 2
last(4,0,1,3) = 3

This can happen if you have RRAs which store more than one step ("step")
per bucket ("steps"). It can also happen at graph time, where the
available RRAs do not make a perfect match with the graph time.

> I do need to read the tutorials again, because I am getting all these
> questions about stuff I thought I understood.

shameless plug of own site:
http://rrdtool.vandenbogaerdt.nl/

The new RRDtool may do things somewhat differently, but the basics should
still apply.

_______________________________________________
rrd-users mailing list
[hidden email]
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
Reply | Threaded
Open this post in threaded view
|

Re: Confusion about VDEF total and graph values

Bram
In reply to this post by Pavel Ruzicka-2
Arjan,

I use 3 databases as well.  But I only write the gas database once per hour, to reduce the wear on the SD card.  As Pavel writes, cards may have wear leveling, which certainly helps prolong the life of the card.  Reducing writes by a factor of 360 is 'free for grabs' so I took it.  Personally, I think it makes creating the graphs using RRD-tool a lot easier, as you do not have to worry about all the bogus zero rates you introduced in the database.  When I now have a zero rate, then I indeed did not use any gas during that period.

Bram
Reply | Threaded
Open this post in threaded view
|

Re: Confusion about VDEF total and graph values

Simon Hobson-2
In reply to this post by Alex van den Bogaerdt-5
"Alex van den Bogaerdt" <[hidden email]> wrote:

>> That would also work visually, but what I had in mind was not to reduce
>> the
>> width, but create the bars by separating them with vertical lines of the
>> correct height.
>
> I have difficulty understanding what you describe here.

I interpret him as : think about drawing each column in the graph as a box with a thin (I guess 1 pixel is the minimum) outline round it in a contrasting colour - but don't draw the top or bottom lines. You've now got vertical lines separating the filled area.

It's slightly more subtle, you actually want to only draw a line on either the right, or the left, of each column - otherwise the side lines from two adjacent columns combine to form a 2 pixel wide line.

It also won't work if the columns are only 1 pixel wide.

_______________________________________________
rrd-users mailing list
[hidden email]
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
Reply | Threaded
Open this post in threaded view
|

Re: Confusion about VDEF total and graph values

humke
In reply to this post by Alex van den Bogaerdt-5
Alex van den Bogaerdt-5 wrote
> Alex van den Bogaerdt-5 wrote
>> You mean you want to see the same bars, only reduced in width? In other
>> words, get smaller bars with gaps inbetween?
>
> That would also work visually, but what I had in mind was not to reduce
> the
> width, but create the bars by separating them with vertical lines of the
> correct height.

I have difficulty understanding what you describe here.
This piece of paint art shows best what I mean. Just smaller bars as per your suggestion would also work. I understand we will still be showing rates, but if the graph visually looks different (more like a histogram) when we CDEF'd a rate, that would be a nice visual cue that we did something to the original data (* 3600 in my case). Of course, title and comment strings could also be used to inform the viewer.



Arjan
Reply | Threaded
Open this post in threaded view
|

Re: Confusion about VDEF total and graph values

humke
In reply to this post by Simon Hobson-2
Simon Hobson-2 wrote
I interpret him as : think about drawing each column in the graph as a box with a thin (I guess 1 pixel is the minimum) outline round it in a contrasting colour - but don't draw the top or bottom lines. You've now got vertical lines separating the filled area.

It's slightly more subtle, you actually want to only draw a line on either the right, or the left, of each column - otherwise the side lines from two adjacent columns combine to form a 2 pixel wide line.

It also won't work if the columns are only 1 pixel wide.
Almost... See my other post of today for a picture of what I mean.

RRDgraph allows us to draw with pixels < 1 in size (I actually use 0.8 in my graphs). There's no such thing as half (or <1) a pixel in reality, but the rendering process uses the number to do some special 'smoothing' (there's a better term that won't pop up in my head) to make it visually look like a thinner line. I am not sure if it would help to give the desired effect in this case. If we could even generate the vertical lines that is which I so much desire ;)

Reply | Threaded
Open this post in threaded view
|

Re: Confusion about VDEF total and graph values

Alex van den Bogaerdt-5
In reply to this post by humke
> This piece of paint art shows best what I mean. Just smaller bars as per
> your suggestion would also work. I understand we will still be showing
> rates, but if the graph visually looks different (more like a histogram)
> when we CDEF'd a rate, that would be a nice visual cue that we did
> something
> to the original data (* 3600 in my case). Of course, title and comment
> strings could also be used to inform the viewer.
>
> <http://rrd-mailinglists.937164.n2.nabble.com/file/n7583447/gas_withlines.gif>

Ack.

AFAIK rrdtool currently does not do this, but you can visualize it
differently.

Two suggestions, both using TIME again. Both assume bars of exactly 1 hour
(3600 seconds) wide. Adjust as needed.  Note: i did not test any of this,
you may need to fix some errors.

#1 two CDEFs.  Both push TIME on the stack, modulo 7200. You have a number
0..7199. Only copy the input if the time is in the {first|second} half of
this range, else push unknown on the stack.
CDEF:val1=orig,TIME,7200,%,3600,LT,orig,UNKN,IF
CDEF:val2=orig,TIME,7200,%,3600,GE,orig,UNKN,IF
now display val1 and val2 using slightly different colors.

#2 two CDEFs again. This time you test against TIME modulo 3600 and
compare using equality only.
CDEF:val1=orig,TIME,3600,%,0,EQ,orig,UNKN,IF
CDEF:val2=orig,TIME,3600,%,0,NE,orig,UNKN,IF
now display val1 in black and val2 using any color you want.

This suggestion only works if RRDtool is working internally with units
much smaller than an hour (or else everything is in val1, displaying only
black). You may need to fetch another data source as well, one that has a
resolution better than one change per hour.  Try this if you see only
black bars.

Once you see bars with black vertical lines (which really are small
areas), you could also display orig in black using LINE1 to fill the top.
The result comes close to your paint art but will not close the gap when a
smaller rate follows a higher one.

Suggestion #3: hack the source. This may not be as simple as it may seem,
but it is certainly doable.

HTH
Alex


_______________________________________________
rrd-users mailing list
[hidden email]
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users