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

[Hamish Whittal]

Hi Alex,

Thanks for looking at my 'problem' in so much detail.

> 
> 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.

Got 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.

I'm doing this. My step size is 300 and my update time is every 5 mins,
making the update and the step size the same. But I seem to be getting
values that are not whole numbers, but floats. i.e. At time "T", I get a
reading of 197 calls. at time T+300, I get 203 calls, T+600 I get 215
calls. Thus, as each interval, I get a whole number of calls per
interval. This is what I want to store. Calls per hour then is simply a
matter of summing 12 of these readings as I understand it.

> 
> 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).

OK, but this would mean that I need to poll my devices every second too,
would it not? Then consolidating the 300x1 sec readings into a 5 minute
interval.

> 
> > 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

This has the obvious disadvantage that rounding anything is incorrect.
If I round up, I may get more calls than were actually made, while
rounding down may produce less calls than actually made.

> 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.

ABSOLUTE, I understand, assumes your counter gets reset after each
reading. Mine does not, so I currently I keep the data as GAUGE. So I
get calls=120, calls=125, calls=180 on each poll (300 secs in my
instance) off the router.


> 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

This is not a true representation that I want to show, since these
'calls per hour' assume that the rate stays constant over the hour for
this 5 minute sample. I would prefer to show 'real' calls per hour as
in:

T+300	= 5 calls
T+600	= 12 calls
T+900	= 6 calls
T+1200	= 15 calls
T+1500	= 9 calls
....

Totals calls per hour was 69.

Thanks Alex for your explinations. I am sure to use them in future
reports.

Cheer
H
--
Hamish Whittal		QED Technologies		Tel: +27 21 448 9291
hamish at QEDux.co.za					Fax: +27 21 448 9551
			`The' Linux Services Company	Cel: +27 82 803 5533

--
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