[rrd-users] !!!LONG!!! Re: Re: Graphing other resolutions....

Alex van den Bogaerdt alex at slot.hollandcasino.nl
Fri Jun 22 23:48:20 MEST 2001

Hamish Whittal wrote:

> > Example: your graph is 400 pixels wide.  You are plotting a certain
> > DS starting from 12:00 today until 13:00 today.  This is 3600 seconds.
> > If each interval is 90 seconds, RRDtool will plot 40 intervals and
> > each interval will be shown on 10 pixels.
> So, the width of the graph is not just giving the width, but also
> controls how the graph looks from a 'smoothness' point of view.

Not really.  It is the combination of pixels and # of intervals that's
important here.  Width alone doesn't say much.  An image with width 400
and only 4 intervals plotted looks quite different from an image with
the same width of 400 pixels and 400 intervals on it.

> Yup, thanx Alex. It does. Just wondering. About my number of calls data
> (telephone calls that is) (that's what I'm plotting), is it possible to
> round this to a whole number. At present, I am getting 4.87 calls per 5
> minutes.

You could fool RRDtool into storing whole numbers.  Just use an update
time that is "compatible" with the step size.  If your database has
intervals of five minutes, update at hh:mm where mm is a multiple of five.

Another approach would be having a step time of 1 second and a CF
of something else than average.  The RRA would still be 5 minutes (and
thus have 300 PDPs per CDP).

> 1) Graph the interval only as an interger (i.e. round it if necessary)

Using CDEF. FLOOR and CEIL come in mind. To determine the closest whole
number you currently have to do the magic yourself.  Something like
AREA:rounded#00CC00:"Number of calls per five minutes"

> 2) Find out the actual value at the time of reading and graph this
> instead.
> Currently, I take 1.6246828434e-02 * 300 and plot that. So I end with
> calls per 5 min. To get calls per hour, I would need to sum 12 such
> values? Yes/No.

Not a yes/no answer as this is not that simple.

Note that graphing telephone calls can be a real pain.

Let's look at a few cases.  As the real time is not important here
I'll just use "T" and an offset to it.  To avoid resampling problems
in these examples, updates occur on interval-boundaries.

a) One call is placed.  It lasts 4 minutes, from T+30 to T+270.
b) Two calls are placed.  T+60 to T+180 and T+120 to T+240
During a measured interval either (a) or (b) happens, no other
calls are placed.

Data aquisition methods:
1) Poll the current number of active lines every 5 minutes
2) Poll the average number of active calls during the last 5 minutes
3) Process the call history, which should include time stamps.

(a) combined with (1): You don't notice the call.  The number of
calls during that interval is 0.
(b) combined with (1): You don't notice the calls.  The number of
calls during that interval is 0.

Obviously this is not the best way to do it.  In extreme situations
you could even have 30 (or 24) calls on your PRI and never notice
that all lines are busy.

(a) combined with (2): You get 0.8 from the device.  The number of
calls during that interval is 0.8 and if you round this you get 1.
(b) combined with (2): You get 0.8 from the device.  The number of
calls during that interval is 0.8 and if you round this you get 1.

Rounding obviously gives wrong results.  You do notice one call
being placed but do not notice that two lines were busy.  Again
in extreme situations you could end up with all lines being busy
without noticing.

(a) combined with (3): You notice the call being setup and being
cleared.  Using both events you can show one call has been active
during that interval, you can show the duration, you can show the
amount of simultanious conversations is 1.
(b) combined with (3): You notice both calls being setup and cleared.
The MAX RRA shows two calls being placed (indicating the number of
simultanious calls), the AVERAGE RRA shows 0.8 indicating the usage
of the box (or, when multiplied with 300: the call time).

This method is the most challenging one but it is also the only
proper one.  The RRD should probably be setup with a step time of
1 second per PDP, 300 steps per CDP, a heartbeat of 300 (or more).

Every update to the RRD should indicate the number of active lines
during the past period.  If no event occurs, just repeat the number
at the interval boundary.

For instance, three calls.  T+60 to T+270, T+120 to T+240, T+180 to
T+360.  The last update to the database has occured at T and was 0.
The current number of lines in use was also 0 at that time.
What to update:

1) T+60.  A call is being setup.  The number of calls during the
   previous time was 0.  Update with 0 at T+60.
2) T+120. A call is being setup.  The number of calls during the
   previous time was 1.  Update with 1 at T+120.
3) T+180. A call is being setup.  The number of calls during the
   previous time was 2.
4) T+240. A call is completed.  The number of calls during the
   previous time was 3.
5) T+300. No event occured but we need to update anyway.  The number
   of calls during the previous time was 2.

Note that processing the log and feeding the numbers to RRDtool is
front-end stuff.  RRDtool is a back-end.

If you would have an RRA with steps==1, the following drawing could
be generated (please view with fixed width font):

|               #####
|          ###############
|     ####################
     |    |    |    |    |
T+   60   120  180  240  300

If you don't have such an RRA but still have a step time of 1, the
values in the 5-minute RRA can be:
AVERAGE:  ( (4/5)+(3/5)+(1/5) ) /3 = 5.3333333e-01
MAX:      3

Using this, a CDEF can output 5.333333e-01 * 300 == 480 seconds of
call during this interval. This is right: 4+3+1 minutes == 8 minutes.
The maximum can be used to prove that there is enough capacity on your
equipment.  Whenever it is fully utilized (or at 80%, or whatever) you
can use the CDEF magic as described in the manual and in the tutorial
to signal the viewer using a different color.

If you're only interested in the number of calls, not all of the
above, this also is a front-end job.  Just count the number of
calls being placed and update it into an ABSOLUTE at time T+300.
RRDtool will convert it to a rate.  When you want to graph, just
multiply the rate by any number of seconds you like.  It doesn't
matter what you choose, 300 or 3600.  It even doesn't matter if
consolidation has happened.  However, there will always be cases
where you end up with a fractional number:

T+ 300:  5 calls  --> rate  5/300==1.666666666e-2
T+ 600:  8 calls  --> rate  8/300==2.666666666e-2
T+ 900: 11 calls  --> rate 11/300==3.666666666e-2
T+1200:  3 calls  --> rate  3/300==1.000000000e-2
T+1500:  0 calls  --> rate  0/300==0.000000000e+0
T+1800:  0 calls  --> rate  0/300==0.000000000e+0

Assuming an other RRA with a number of steps that is 6 times as large
as the other RRA, this will be consolidated into:

T+1800: rate == [previous rates summed and divided by 6] == 1.5000e-2

If you plot this number as number of calls per five minutes, you
will end up with 300*0.015 == 4.5 calls per 5 minutes, this number
is valid during the one interval from T to T+1800.

You can also multiply by 3600 and get the number of calls per hour.
This can also be done for the 5-minute intervals:

T+ 300: 1.666666666e-2  -->  60 calls per hour
T+ 600: 2.666666666e-2  -->  96 calls per hour
T+ 900: 3.666666666e-2  --> 132 calls per hour
T+1200: 1.000000000e-2  -->  36 calls per hour
T+1500: 0.000000000e+0  -->   0 calls per hour
T+1800: 0.000000000e+0  -->   0 calls per hour


T+1800: 1.500000000e-2  -->  54 calls per hour.

 / alex at slot.hollandcasino.nl                  alex at ergens.op.het.net \
| work                                                         private |
| My employer is capable of speaking therefore I speak only for myself |
| Technical questions sent directly to me will be nuked. Use the list. | 
| http://faq.mrtg.org/                                                 |
| http://rrdtool.eu.org  --> tutorial                                  |

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