[rrd-users] Incorrect numbers returned when monitoring network stats at one second intervals

Alex van den Bogaerdt alex at ergens.op.het.net
Thu Jul 26 17:19:52 CEST 2007

On Thu, Jul 26, 2007 at 09:22:29AM -0400, Mark Seger wrote:

> I guess I have to differ on your conclusion.  When one has a tool that 
> is reporting bytes/sec and it occasionally reports an invalid number 
> like 200MB/sec on a 1G link, they at least owe an explanation to their 
> users why this is the case.  When doing detailed analysis of system 

I have to agree with Mark here.  The numbers aren't wrong, your
analysis of them is.

The system is reporting counter values, not network rates. You are
converting those values into rates and while doing so you find that
there is a limitation.

Don't forget: bytes per second is still an average and an approximation.
What you are arguing about is equally valid for data measured per
1.0000000000000000000 seconds.

What about a frame that is partially transmitted before you take
a snapshot of the counters, and partially thereafter? What if three
frames are transmitted in two units of time?

Why would 1 second be good and 300 seconds not?  After all, the error
will increase as the time interval decreases, perhaps a 300 second
interval is better than a 1 second interval.

But what about peak values lost?  Well, decrease your interval further
from one second down to milliseconds or beyond, and eventually you
will find that there is a byte transmitted, or there is not.  So,
the peak value will always be 100% of the link capacity.

I think what you really want to know is latency and packet loss.
There is no problem if the network is transmitting at (e.g.) 99 MBps
on a 100 MBps link. That's why it's there.  The problem occurs if
you want to transmit data but have no capacity (resulting in a delay),
or cannot reach the destination (e.g. dropped frames).

my 2ct.

I won't respond to this thread for at least a couple of days.  That
is because of having limited internet access (if at all), not due to
other reasons.

More information about the rrd-users mailing list