[rrd-users] Re: SNMP Total Traffic
don.baarda at baesystems.com
Thu Jan 18 02:36:18 MET 2001
> -----Original Message-----
> From: Clifton Royston [SMTP:cliftonr at lava.net]
> Sent: Wednesday, January 17, 2001 6:22 AM
> To: Alex van den Bogaerdt
> Cc: Aragon Gouveia; RRD users
> Subject: [rrd-users] Re: SNMP Total Traffic
> On Mon, Jan 15, 2001 at 07:30:34PM +0100, Alex van den Bogaerdt wrote:
> > The average number of bytes per second, multiplied with the number of
> > seconds, gives you the number of bytes...
> > So: display exactly one week and read the average.
> Not necessarily, depending on the prevalence of NANs stored in the
> RRD, e.g. for intervals when the device was not being queried or when
> it was unreachable. An artifact of computing it this way is that you
> can lose the accuracy of the data by transforming it to a rate and back
> The RRD will store NANs for the rate for this period; the NANs will
> be ignored when constructing the average rate for the period. Hence
Note that this is equivalent to assuming "unknowns" are at the
average rate of the "knowns" over the total period. This is a good
approximation given that some of the data you want to average is unknown.
Possibly a better approximation would be to assume that the "unknown" PDP's
are at the average of the known PDP's immediately before and after them, but
it is debateable, and heaps more complex.
> the reconstructed data could be incorrect, because any such intervals
> will be left out of the calculation (even though the byte counter value
> before and after the interval was known), and hence the total number of
> bytes calculated in this way could be more or less than the real value.
> The adjustments RRD does in "averaging" the data might further compound
> the problem.
> I have been wrestling with this issue myself and don't have a good
> solution yet.
The solution is to recognise what an "unknown" means in the RRD, and
configure things so the only "unknowns" that end up in the RRD are genuinely
"unknown", and that your accumulation handles "unknowns" how you want them
For example... with a counter and 5min samples, if you miss sampling
for 30 minutes, are the PDP's for that 30 minutes really unknown? That
depends on whether you care about the accuracy of your 5min samples. You
have the counter values at the beginning and end of that 30min period so you
do know the average rate for that 30mins. If you care about the accuracy of
the 5min PDP's, then you might consider them unknown, but if the average
over that period is meaningful to you, then you might want to set your
For traffic counting purposes, the total count of bytes is more
important than the accuracy of each PDP. This means you'd rather know the
true average rate for a whole day than mark it "unknown" because you only
got samples at the beginning and end of that day and have a 5 minute step.
If you want accurate accumulation for traffic counting purposes, I'd
set heartbeat very high. Think of the heartbeat setting as your "coarsest
acceptable resolution", and step as the "finest possible resolution". A
heartbeat of 1 day means accumulated averages over greater than a day will
be accurate, even if the 5minute PDP's within that day are not entirely. The
only thing to be wary of with large heartbeats is counter wrap-around; if
you make it too big, the counters can wrap so far RRD doesn't notice.
Probably the optimal heartbeat for traffic counting is min(
min_counter_wraparound_time, max_period_tolerance), where
max_period_tolerance is the largest variation in the start/end times of
accumulation periods you can live with... ie totals for every 1month +- 1day
> -- Clifton
> Clifton Royston -- LavaNet Systems Architect -- cliftonr at lava.net
> The named which can be named is not the Eternal named.
> 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
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