linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Sipek <jeffpc@optonline.net>
To: "Randy.Dunlap" <rddunlap@osdl.org>
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 13:55:14 -0400	[thread overview]
Message-ID: <200307251355.22161.jeffpc@optonline.net> (raw)
In-Reply-To: <20030725102043.724f4a3b.rddunlap@osdl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 25 July 2003 13:20, Randy.Dunlap wrote:
> Yes, a common solution for this is to use some SNMP agent that does
> 64-bit counter accumulation.

Interesting...I haven't thought of SNMP.

> 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>

It is just easier to have everything 64-bits.

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

Agreed, however if we are going to change some counters, we should do it for 
all of them. (Btw, /proc is not the only point where users can get stats.... 
there is also /sys and something else...I can't remember now...)

Jeff.

- -- 
Research, n.:
  Consider Columbus:
    He didn't know where he was going.
    When he got there he didn't know where he was.
    When he got back he didn't know where he had been.
    And he did it all on someone else's money.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/IW8GwFP0+seVj/4RAhf3AKDAtCkm8UdL4T1ZQzqttEG7XyVW9ACeIT6m
RKO8c2UnpSuJwyvwHd5PS8c=
=4vls
-----END PGP SIGNATURE-----


  reply	other threads:[~2003-07-25 17:42 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
2003-07-25 17:55         ` Jeff Sipek [this message]
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=200307251355.22161.jeffpc@optonline.net \
    --to=jeffpc@optonline.net \
    --cc=ecki-lkm@lina.inka.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rddunlap@osdl.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).