Precise per GB traffic calculations.

Does anyone know of a solution that offers precise methods of tracking bandwidth utilizations at the per Megabyte or Gigabyte level and not at the rate of transfer level?

Some people are asking me if we can bill them in this manner, and I’m questioning whether the stats that the switch are giving us are that accurate.

Hit me off-list.

Thanks,

-Drew

Date: Fri, 20 Aug 2004 17:06:42 -0400
From: Drew Weaver

Does anyone know of a solution that offers precise methods of
tracking bandwidth utilizations at the per Megabyte or
Gigabyte level and not at the rate of transfer level?

Rate of transfer is determined using byte counters.

Eddy

> Does anyone know of a solution that offers precise methods of
> tracking bandwidth utilizations at the per Megabyte or
> Gigabyte level and not at the rate of transfer level?

Rate of transfer is determined using byte counters.

[Eddy is saying "yes" in the above line].

I'm not sure that would be clear to me if I didn't already know the answer to the question. Forgive the Friday afternoon curve.

DJ

I don't know of any equipment that does NOT measure per-byte transferred. The Mbps is done by taking the bytes transferred (multiply by 8) and divide by the time involved, usually 5 minute periods.

            Does anyone know of a solution that offers precise methods of
tracking bandwidth utilizations at the per Megabyte or Gigabyte level and
not at the rate of transfer level?

I've used a tool called "IOG", which works to some extent, but it looks
like it has problems with 64bit counters.

Some people are asking me if we can bill them in this manner, and I'm
questioning whether the stats that the switch are giving us are that
accurate.

Imagine this scenario:
Customer Buys 600GB of "transfer"
Customers transfers 600GB @ 100Mbps for however many hours.

If you're being billed with 95th percentile, and your customer is being
billed on transfer, guess who gets the short end of the stick...

simple but should work, do this with mrtg, set the data type to 'absolute' and
zero it at the start of each month, it will give you the total in a month.

Drew,

Your counters probably reset a couple of times during the month, when they
reach some maximum value. Or perhaps because somebody power cycles the
switch.

So, no, it's not a good idea to look at the counter on day 1 and on day 30
and compare them. Check it every 5 minutes and store it in a database.
That way, the same system can do aggregate or 95th percentile, it's all in
the report script you write.

Andy

: On Aug 20, 2004, at 5:06 PM, Drew Weaver wrote:
:
: > ����������� Does anyone know of a solution that offers precise methods
: > of tracking bandwidth utilizations at the per Megabyte or Gigabyte
: > level and not at the rate of transfer level?
:
: I don't know of any equipment that does NOT measure per-byte
: transferred. The Mbps is done by taking the bytes transferred
: (multiply by 8) and divide by the time involved, usually 5 minute
: periods.

I just want to point out that this is not a strict average over 5 minutes
in the case of cisco's output for the "show interface" bits per second.
It's an exponentially weighted average:

http://cisco.com/en/US/products/sw/iosswrel/ps1818/products_tech_note09186a0080191323.shtml

     Bits per second include all packet/frame overhead. It does not
     include stuffed zeros. The size of each frame is added to the total
     bytes of output. The rate is calculated by taking the difference
     every 5 seconds. The algorithm for the five-minute moving average
     is:

     new average = ((average - interval) * exp (-t/C)) + interval

     where:
     - t is five seconds and C is 5 minutes. exp(-5/(60*5)) == .983
     - newaverage = the value we are trying to compute
     - average = the "newaverage" value calculated from the previous
                 sample
     - interval = the value of the current sample
     - (.983) is the weighting factor

     What you are basically doing is taking the average from the last
     sample less what we gathered in this sample and weighting that down
     by a decay factor. This quantity can be referred to as an "historical
     average". To the weighted (decayed) historical average, we add our
     current sample and come up with a new weighted (decayed) average.

scott