# [rrd-users] Graphing COUNTER values absolutely

Simon Hobson linux at thehobsons.co.uk
Wed Mar 19 13:22:23 CET 2008

```Felix Castillo Sanchez wrote:

>  > > I'm storing Oracle performance values that are continuously increasing.
>>  The
>>  > problem is that a user cannot handle a per second rate because we're
>>  talking
>>  > about centiseconds within 5 minutes. So how do I explain an end user
>>  that
>>  > sub-microseconds of wait time can be a performance bottleneck?!
>>
>>  Why do you think that it is easier to explain when you multiply
>>  the number by some arbitrary value?
>
>I don't want an arbitrary value - I want to have the rate per second
>multiplied by the seconds that lie between the data points.

Do you mean between fixed intervals (eg every 5 minutes), or between
arbitrary points (eg last changes occurred at 12:04:01, 12:04:07,
12:10:57) ?

If it's the former, then simply multiply the stored rate by 300 and
you have '<somethings> per 5 minute period'.

If it's the latter then rrd is not the right tool for the job.

To expand on that a bit.

Taking the fixed intervals case, suppose that you last samples were
0, 5, 10, and 15 - all at exactly 300 second intervals. The rate is
'5/300 <somethings>/second', or '300 * 5/300 <somethings>/5minute
period'.

Taking the second case, then I think what you are looking at is a
bunch of <somethings> happened at 12:04:01 then nothing until
12:04:07 when another bunch of <somethings> happened. Then a gap
until 10:10:57 when another bunch happened. You then want to be able
to show a user that "you did <x>, the result was that <y somethings>
happened while the system was processing job <x>". RRD will NOT store
this information<period> It isn't what it's designed to do.

If each bunch was 5 events, and an update was triggered at each
event, and the step size was 5 minutes, then in the period 12:00:00
to 12:05:00 it would store :
- whatever came before 12:04:01 (we'll assume zero for now)
- plus 5 events between 12:04:01 and 12:04:07
- plus 53/(53+300+57) * 5 between 12:04:07 and 12:05:00

All this combined would store a rate of 5.64634145/300s or 0.018821138/s

for 10:05:00 to 12:10:00 it would store a rate of 300/(53+300+57) * 5
or 3.6585366/300s or 0.012195122/s

the remaining 57/(53+300+57)*5 would go into the 12:10:00 to 12:15:00
bin together with a fraction of future updates.

See the tutorials on data normalisation (see the rrdtool website) for
more details.

```