From owner-freebsd-net Thu Dec 16 23:30:47 1999 Delivered-To: freebsd-net@freebsd.org Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by hub.freebsd.org (Postfix) with ESMTP id 85ABC14E78 for ; Thu, 16 Dec 1999 23:30:42 -0800 (PST) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.0) with SMTP id SAA20711; Fri, 17 Dec 1999 18:29:01 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 17 Dec 1999 18:29:01 +1100 (EST) From: Ian Smith To: Mike Nowlin Cc: Aldrin Leal , freebsd-net@FreeBSD.ORG Subject: Re: Math Help for IPFW :) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 17 Dec 1999, Mike Nowlin wrote: Sure you can use SNMP also, or instead, but if you want to do it from your gathered IPFW data, why not just use the byte counters rather than or as well as the packet counters, per rule? (almost) works here .. we're starting to analyse `ipfw -t show >> file` cronned every 5 minutes for 1.5 yrs (and running MRTG for the visuals). Cheers, Ian > > How could i relate this count, the second one, for packets? For sure it > > means the number of packets processed. But how long is a packet? That's all > > i need to put the right number of kBPS/s they're doing. :) > > The first problem is that packet size varies greatly -- it could be a > single byte (plus header/address information), or quite large, depending > on what the interface type/parameters are set for. > > The best solution I found for this is SNMP, which is what most of the "big > boys" (PSI Net, for example) use. I do something similar -- sample the > "interfaces.ifTable.ifEntry.ifOutOctets" and > "interfaces.ifTable.ifEntry.ifInOctets" entries for each interface > periodically, and you can calculate the average bandwidth usage per > interface pretty easily: > > (with two samples, taken x seconds apart) > > Bandwidth = (sample1 - sample2) / x > > Not perfect, but it works. The closer in time the samples are, the more > accurate your result. Using ucd-snmp, it's pretty easy to write a perl or > shell script that will do this for you on a routine basis, and send it to > some reporting method. > > mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message