All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Sipek <jeffpc@optonline.net>
To: Fredrik Tolf <fredrik@dolda2000.cjb.net>,
	Bernd Eckenfels <ecki-lkm@lina.inka.de>,
	linux-kernel@vger.kernel.org
Subject: Re: Net device byte statistics
Date: Thu, 24 Jul 2003 23:54:08 -0400	[thread overview]
Message-ID: <200307242354.17224.jeffpc@optonline.net> (raw)
In-Reply-To: <200307250437.50928.fredrik@dolda2000.cjb.net>

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

On Thursday 24 July 2003 22:37, Fredrik Tolf wrote:
> On Friday 25 July 2003 02.22, Bernd Eckenfels wrote:
> > it is for performance reasons. You can
>
> I almost thought that would be it. I do understand that that code needs to
> be really clean, but, correct me if I'm wrong, but isn't GCC's long long
> implementation efficient enough to only add minimal overhead to that? On
> IA32, it shouldn't take more than one or two more instructions (per
> counter),

That is the problem. Nobody can tell what is going to happen between those 
extra instructions. The worst case scenario would be statistics off by 4GB.

> and it seems to me that net_device_stats should still be small
> enough to avoid any more cache misses.
> I'm no expert, of course, so if I'm wrong, please tell me.
>
> > a) collect your numbers more often and asume wrap/reboot  if numbers
> > decrease
> > b) use iptables counters instead
>
> Currently, I'm sampling once a day, and although sampling more often could,
> of course, solve the problem, it's just that I don't think that it should
> be necessary.

There needs to be an implementation that is very friendly to the performance.

> Do the iptables counters take the whole packet into account, or do they
> ignore the ethernet header?

I have no idea.

> > BTW: it is a very often discussed topic, personally (as net tools
> > maintainer) I would love to see 64bit counters here, but this still means
> > you have to sample often enough, so you do not lose numbers on crash.
>
> While that is true in theory, I'm just using it to estimate my home net
> usage, and my router hasn't crashed this far, so I'm not very worried about
> that.
>
> Thank you very much for your input. For now, I'm just going to implement 64
> bit counters in my kernel.

May I ask how and which kernel version?

Jeff.

- -- 
A lot of my debugging happens in the shower.
		- Zwane Mwaikambo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/IKnowFP0+seVj/4RAp5xAJ48QIdsoo2uzZMoARh3pXeLa3ZgoACgnKSG
X9bSWvQu0u3s1jWYdN7+Dxk=
=PNeu
-----END PGP SIGNATURE-----


  parent reply	other threads:[~2003-07-25  3:39 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 [this message]
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
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=200307242354.17224.jeffpc@optonline.net \
    --to=jeffpc@optonline.net \
    --cc=ecki-lkm@lina.inka.de \
    --cc=fredrik@dolda2000.cjb.net \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.