[rrd-users] Re: !!!LONG!!! Re: Re: Graphing other resolutions....
hamish at QEDux.co.za
Mon Jun 25 18:35:12 MEST 2001
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.
> > 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
> > 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
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
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
More information about the rrd-users