[126592] in North American Network Operators' Group
Re: Useful TCL script?
daemon@ATHENA.MIT.EDU (James Hess)
Sun May 23 19:14:02 2010
In-Reply-To: <AANLkTinppiDzT7LpIdsLW0PjWVIDgi8IXexexwvo_dEl@mail.gmail.com>
Date: Sun, 23 May 2010 18:13:49 -0500
From: James Hess <mysidia@gmail.com>
To: Christopher Gatlin <chris@travelingtech.net>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Sun, May 23, 2010 at 5:16 PM, Christopher Gatlin
<chris@travelingtech.net> wrote:
> That is a stellar TCL script!
> I generally use netflow to glean information regarding average packet size.
Seems like a good script to me. My only criticism would be pretty
hard to do anything about... you're averaging an average over a
longer period of time than the underlying data that computes the
average. dividing 5 minute average databytes approximation by 5
minute average packets approximation is probably not a very
reliable estimate for 5 minute average packet size.
Even ignoring roundoff errors, an amount of error is introduced by
averaging less precise samples, than the device should have access to
(if it could compute that rolling average itself using 1 minute or
higher resolution data)
The less stable the packet size, the more error your approximation should have.
Example of 5 minute average over 5 60-second bps divided by
pps samples...
Versus taking the two 5 minute average rates and dividing them.
60sec average after
1min 2min 3min 4min 5min | Actual 5
minute average rate
|
bps 100000 200000 300000 400000 850000 | 370000
pps 600 300 900 1000 3620 | 1284
bps/pps 166.67 666.67 333.33 400 234.80 | 360.294
BPS / PPS that would be computed by 370000 / 1284 = 288.16 bits
When 360.294 bits should be the answer, is an error of 72.134
bits (or 9 bytes out of 45 bytes),
Representing an introduced error of ~20%
--
-J
