linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Randy.Dunlap" <rddunlap@osdl.org>
To: Jeff Sipek <jeffpc@optonline.net>
Cc: vda@port.imtp.ilyichevsk.odessa.ua, ecki-lkm@lina.inka.de,
	linux-kernel@vger.kernel.org
Subject: Re: Net device byte statistics
Date: Fri, 25 Jul 2003 10:20:43 -0700	[thread overview]
Message-ID: <20030725102043.724f4a3b.rddunlap@osdl.org> (raw)
In-Reply-To: <200307251223.51849.jeffpc@optonline.net>

On Fri, 25 Jul 2003 12:23:37 -0400 Jeff Sipek <jeffpc@optonline.net> wrote:

| -----BEGIN PGP SIGNED MESSAGE-----
| Hash: SHA1
| 
| On Friday 25 July 2003 03:03, Denis Vlasenko wrote:
| > I sample the data every minute. Will need to do it much more often
| > on 10ge ifaces, when those will appear at my home ;)
| 
| Speed			Time for one overflow
| 
| 10Gbits/s	=> 3.436 seconds
| 1Gbit/s		=> 34.36 seconds
| 100Mbits/s	=> 343.6 seconds
| 
| > Or we will need 64bit counters then.
| 
| For anything up to (and including) 1GBit/s it is possible to do in easily in 
| userspace, but then were are getting into an area where a program would have 
| to check the files every 3 seconds (and a bit of load could delay it long 
| enough for an overflow to happen.)

Yes, a common solution for this is to use some SNMP agent that does
64-bit counter accumulation.

IETF expects that some high-speed interfaces will have 64-bit
counters.  From RFC 2233 (Interfaces Group MIB using SMIv2):

<quote>
For interfaces that operate at 20,000,000 (20 million) bits per
second or less, 32-bit byte and packet counters MUST be used.
For interfaces that operate faster than 20,000,000 bits/second,
and slower than 650,000,000 bits/second, 32-bit packet counters
MUST be used and 64-bit octet counters MUST be used. For
interfaces that operate at 650,000,000 bits/second or faster,
64-bit packet counters AND 64-bit octet counters MUST be used.
</quote>

However, this is a MIB spec.  It does not require a Linux
(/proc) interface to support 64-bit counters.

--
~Randy

  reply	other threads:[~2003-07-25 17:08 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-24 23:56 Net device byte statistics Fredrik Tolf
2003-07-25  0:22 ` Bernd Eckenfels
2003-07-25  2:37   ` Fredrik Tolf
2003-07-25  3:26     ` Bernd Eckenfels
2003-07-25  3:49       ` Jeff Sipek
2003-07-25  3:54     ` Jeff Sipek
2003-07-25  7:03   ` Denis Vlasenko
2003-07-25  7:01     ` Andre Hedrick
2003-07-25 16:23     ` Jeff Sipek
2003-07-25 17:20       ` Randy.Dunlap [this message]
2003-07-25 17:55         ` Jeff Sipek
2003-07-25 17:58           ` Randy.Dunlap
2003-07-25 21:55             ` jw schultz
2003-07-25 22:51               ` Jeff Sipek
2003-07-26  0:08                 ` Ben Greear
2003-07-26  0:44                   ` jw schultz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030725102043.724f4a3b.rddunlap@osdl.org \
    --to=rddunlap@osdl.org \
    --cc=ecki-lkm@lina.inka.de \
    --cc=jeffpc@optonline.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vda@port.imtp.ilyichevsk.odessa.ua \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).