[rrd-users] Re: CDEF - creating a increasing series

ciaran deignan ciaran.deignan at netcelo.com
Tue Sep 7 18:23:04 MEST 2004


Hi Alex,

I'm just coming back to my traffic counter "questions"...

Thank you for your previous reply concerning alignment. I understand vaguely
what you're saying, I haven't had the time to implement it yet. However 
I would
expect those obverstations to have an impact of a few percent (like 
rounding or
sampling errors)...


>>but the effective step is decided automatically by RRD depending on the 
>>size of the graph, and RRD doesn't appear to make this value available
>>to CDEF operations :(
>>
>
>With step you probably try to describe the amount of time in each column.
>This is something different than "step", which is the amount of time per
>
Well, the rrdtool graph does take a "step" parameter. But as the manpage 
says:

RRDG> **-S*|*--step* /value/ (default automatic)
*RRDG> By default *rrdgraph* calculates the width of one pixel in the time
RRDG> domain and tries to get data at that resolution from the RRD. With
RRDG> this switch you can override this behavior. If you want *rrdgraph* to
RRDG> get data at 1 hour resolution from the RRD, then you can set the step
RRDG> to 3600 seconds. Note, that a step smaller than 1 pixel will be
RRDG> silently ignored.


So... the byte counters are converted to rates. To get back to volumes
you have to multiply by the time between two displayed values.
However that time is the largest of "start-end/width", the "step size
times steps per CDP" and the "display-step".
Complicated.

Currently I'm trying to calculate the volumes seperately from the
actual graph generation, like this:

        Val=$(rrdtool graph /dev/null \
                --start -1week --end -2minute --step $step \
                DEF:Bin=$rrdfile:InOctets:AVERAGE \
                DEF:Bout=$rrdfile:OutOctets:AVERAGE \
                CDEF:tin=PREV,UN,0,PREV,IF,Bin,UN,0,Bin,IF,$step,*,+ \
                CDEF:tout=PREV,UN,0,PREV,IF,Bout,UN,0,Bout,IF,$step,*,+ \
                PRINT:tin:LAST:"Tin=%.2lf;" \
                PRINT:tout:LAST:"Tout=%.2lf;" | grep -v 0x0)

(I know, I should be doing the calcualtion on clean boundries within
the RRD object.... soon ;)

When I use this command to calculate a week's traffic, I get
different results depending on the step:

Step    In              Out
600  21080378.37    41507111.69
1200 42160756.73    83014223.38
1800 63241135.10    124521335.08
2400 42174276.45    83045573.93
3600 63261414.68    124568360.90


very oddly (for me) the values obtained for step 600, 1200 and 1800
are multiples (maybe the rate shouldn't be multiplied by the step?)!

OK, if all this is due to the rounding errors that I'm ignoring, I'm
very sorry for occupying the collective bandwith...

My object is declared like this (step 60):
                DS:InOctets:COUNTER:360:0:600000 \
                DS:OutOctets:COUNTER:360:0:600000 \
                RRA:AVERAGE:0.5:1:1500 \
                RRA:AVERAGE:0.5:10:8928 \
                RRA:AVERAGE:0.5:60:8880
(1500 is a day, 10*8928 is 2 months)

RRD seems to be inadapted to this task, but RRD always reminds me
of Judo or something like that - once you find the right approch
everything becomes simple ;) Maybe the magic option is there and I'm
not seeing it!


>If you want to know in advance how much time each column will contain,
>do not use "now" (not written by you, nor implicit).  Use an end-time
>that is a whole number times the step size times steps per CDP.
>Do the same for the start-time.
>Make sure both start and end are inside the RRA that will be used.
>
>If "step" is 300, and "steps" is 6, use an end time that is "n*1800".
>If the amount of time included in the RRA is one week, do not exceed
>that amount.
>
>Do NOT use "--end now --start end-24h" because end is probably not n*1800.
>Do NOT use "--start end-24h" because that contains an implicit "end now".
>Do NOT use "--end 00:00 --start end-8d" because that is more time than
>RRDtool can find in the RRA and thus will select another RRA.
>
The only rule I'm not breaking is staying inside the RRA... I think ;)

cheers
Ciaran

--
Unsubscribe mailto:rrd-users-request at list.ee.ethz.ch?subject=unsubscribe
Help        mailto:rrd-users-request at list.ee.ethz.ch?subject=help
Archive     http://www.ee.ethz.ch/~slist/rrd-users
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi



More information about the rrd-users mailing list