[rrd-users] VDEF MINIMUM

[Oliver]

Hi Alex,

Thanks for that, I'll study this some more.

For now I'm doing it the "messy" way, i.e. fetch-ing all the data into an 
array, sorting it numerically ascending and then taking the first and last 
values of the array as minimum and maximum values plotted on the graph.

As I say it's not as clean as using an rrdtool function directly to extract 
min/max, but it seems to give results which correlate exactly to the minimum 
and maximum points plotted on the graphs which is the main thing.

Thanks,
Oliver.

-----Original Message----- 
From: Alex van den Bogaerdt
Sent: Thursday, August 11, 2011 11:05 PM
To: Oliver
Cc: rrd-users at lists.oetiker.ch
Subject: Re: [rrd-users] VDEF MINIMUM

bottom paragraph of my reply, "... the other ..." is the relevant part
then. You want to display a certain amount of RRA rows in less the amount
of pixel columns, so RRDtool is going to do some on the fly consolidation.

Try an end time which is n*60, try to display 400*60 seconds, do so in 400
pixel columns.
GPRINT last, min, average, max.
Now try the same, except that you display 400*30 seconds.

This part of the tool has had more than its fair share of problems in the
past, I seem to recall an off by one error or two, and other problems.
There could be differences between the various RRDtool versions, but all
versions will have some form of on the fly consolidation, where multiple
RRA rows will be combined into one pixel row.

Once you understand the relatively easy n*30 vs. n*60 case, try to figure
out what the tool does with n*40, n*50 and so on.

GPRINTing the time component of the first and last sample on the graph may
also be interesting.

cheers,
Alex


> Hi Alex,
>
> Thank you for your detailed reply which has certainly helped me understand
> RRA calculations a bit better.
>
> However I am only using one RRA (I should have pointed this out in my
> first
> post):
>
> filename = "noise.rrd"
> rrd_version = "0003"
> step = 30
> last_update = 1313098265
> ds[noise].type = "GAUGE"
> ds[noise].minimal_heartbeat = 60
> ds[noise].min = NaN
> ds[noise].max = NaN
> ds[noise].last_ds = "9.4"
> ds[noise].value = 5.6364270600e+01
> ds[noise].unknown_sec = 0
> rra[0].cf = "AVERAGE"
> rra[0].rows = 5760
> rra[0].cur_row = 4995
> rra[0].pdp_per_row = 1
> rra[0].xff = 5.0000000000e-01
> rra[0].cdp_prep[0].value = NaN
> rra[0].cdp_prep[0].unknown_datapoints = 0
>
> Does this influence your previous reply?
>
> Thanks,
> Oliver.
>
> -----Original Message-----
> From: Alex van den Bogaerdt
> Sent: Tuesday, August 09, 2011 2:00 PM
> To: rrd-users at lists.oetiker.ch
> Subject: Re: [rrd-users] VDEF MINIMUM
>
> You are looking at averages. Your two tests use different RRAs. For
> instance: one RRA consolidates 1 PDP into 1 CDP, the other consolidates 3
> PDPs into one CDP. Look at 10,20,30,40,50,60. One RRA has all 6 values,
> the other RRA has average(10,20,30) equals 20, average(40,50,60) equals
> 50.
>
> minimum(10,20,30,40,50,60) equals 10. minimum(20,50) equals 20. Your test
> would return 10 and 20.
>
> It should work much better if you look at minimums of minimums:
>
> The other RRA would contain min(10,20,30) equals 10, min(40,50,60) equals
> 40. Then min(10,20,30,40,50,60) and min(10,40) both return 10.
>
> There can be two places where consolidation takes place. One is when data
> is copied into RRAs, the other is when rrdtool graph needs data in a
> resolution which is not available. If you take both into account, you
> should be able to get predictable results.
>
> HTH
> Alex
>
> _______________________________________________
> rrd-users mailing list
> rrd-users at lists.oetiker.ch
> https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
>
>