# [rrd-users] problems with rrd and check_traffic

Simon Hobson linux at thehobsons.co.uk
Wed Apr 4 17:25:23 CEST 2007

```Henrique Silveira Cadore wrote:

>The graphic generated shows me the average each 5 minutes. shouldnt
>it be every minute since im updating the database every minute?

No, I suggest you try and understand what rrd is doing for you.
Specifically, except under certain very specific circumstances you do
NOT get out what you put in.

I does not matter how often you update, the rrd only contains a
simgle data point for each <step> of time, in this case 5 minutes. No
matter how frequently, or infrequently, you provide data, it is
always normalised to these <step> sized sample periods. To give a
very simple example, suppose you have a step size of 5 minutes (300s)
and update every 2 minutes (120s), not ideal but it shows a couple of
points. Further, lets assume you are able to provide the updates when
the time (seconds since epoch) is an exact multiple of 120 seconds.

You need to be using a fixed pitch font for this :

Update   x   a   b   c   d   e   f
Store    |         |         |

The first 2 samples (a & b) plus half of the third (c) will be used
for the first stored interval, the other half of sample c plus the
next 2 samples (d & e will be used for the next interval, and so on.
If the data is at a constant rate of 1/second then your updates would
go like this :

Update a : rate is 1, so 120 (1/s x 120s) is added to the temporary store.
Update b : rate is 1, so 120 (again 1/s x 120s) is added to the store.
Update c : rate is still 1, but this time only 60 (1/s x 60s) is
added to the store to give a total of 300, this is divided by 300 to
get 1/s which is entered into the appropriate slot in the rrd. The
other 60 is then placed in the store having first removed the 300
from the previous time slot.

If the rate is increasing, you might have the following :
update a : rate is 2/s, so add 240 (2/s * 120s)
update b : rate is 3/s, so add 360
update c : rate is 4/s. Add 240 (4/s * 60s) to get 840, divide by 300
to get 2.8 which goes into the rrd, finally put the other 240 into
the store.

Note that other than the internal accumulator used in the
normalisation process, the values you feed it are never stored
directly into the RRD.

That's what the rrd contains, but it doesn't have to be what if
graphed. You could take that rrd and graph it with an interval of 10
minutes/step, and assuming you ask for average, then each pair of
samples will be averaged and plotted as one point. It is not even
essential to have the graph as an integer multiple of the sample
period, the program will apply a similar normalisation process to
match the stored data to points on the graph - but obviously every
such transform is going to further obscure the original data points
fed in.

If you can understand this fundamental different from an 'ordinary'
database then you will better understand how to get the right results
out.

```