Subject: Re: Resetting ip, icmp etc statistics
To: Liam J. Foy <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 04/03/2006 16:54:44
Content-Type: text/plain; charset=us-ascii
On Mon, Apr 03, 2006 at 06:50:27PM +0100, Liam J. Foy wrote:
> On 09:44, Mon 03 Apr 06, Bill Studenmund wrote:
> > Huh? What you said touches on point (2) above, but not on any of the ot=
> > points. Sure, we can make it so we only incriment one counter, but that=
> > the easy part of all this.
> I was only touching on point (2) =3D)
> > The "magic" is that userland thinks there are multiple counters when th=
> > aren't (I think it'd be a bad idea to make userland fetch a counter and=
> > offset and have to do the subtraction).
> Why do you think this is a bad idea? I've been playing around and kinda
> implemented whats been discussed. I've two sets of counters, the
> original counters and another identical set. Right now 'netstat -Zp ip'
> will checkpoint the counters(IP) by copying the original counters, or 'ra=
> counters, over to the checkpoint stats struct.
Because I think it's simpler and cleaner. Note: I'm assuming that both the=
running and checkpointed counters are in the kernel. I think it's simpler=
as we only export "running" and "since-checkpoint" counters, and the only=
operation permitted by userland is to set the checkpoints to the current=20
I'm not sure if I read you right, but I'd be very concerned about letting=
userland load new "last-checkpoint" counters. "Set checkpoints to raw" is=
very easy to audit and to log ("user X pid Y reset counters Z"). It's also=
a simple operation to expose. "Load these checkpoint values" seems like a=
much more abusable way to manipulate the counters. I think if an=20
administrator wants to play games like that, s/he should do it in=20
If the checkpointing were done totally in userland (kernel only knew about=
raw counters), then obviously userland would have to deal with the math.=20
> You can then do 'netstat -szp ip' to few the difference since the
> checkpoint creation.
> I'm just using netstat for now, this can of course easily be changed.
I think what you're doing is fine for the command lines, however please
look at ifconfig too. Right now, -z will zero the counters in ifconfig. I
think it'd be bad if the command option to show since-zeroed counters in
one command was the same as the one to zero counters in another command.
> > But points (1) and (2) are the easy ones. They aren't why I think separ=
> > counters are too much work for the benefit. That's in points (3), (4), =
> > the lack of scalability. :-)
> Not all programs need to know (as you said in point(3)). I don't see how
> point (3) is valid.
It's a matter of consistency. How many programs display stats in a=20
semi-interactive (or fully-interactive) manner? By that I mean not SNMP=20
consoles or things that only need "raw" counters and do magic themselves.
It could be that netstat and ifconfig are the only ones in base. But=20
systat may also need changing. But then supporting this feature becomes a=
pkgsrc porting issue as well. :-(
It's also an issue of consistency. With not having checkpointing in the=20
kernel and only zeroing the "raw" counters, only the zeroing program needs=
change. With the checkpointing you're describing, everything has to learn=
And everything really should use a similar interface. Having '-z' zero for=
some apps and report zeroed-based (checkpointed) counters in another is=20
bad. ifconfig -z has zeroed since NetBSD 2.0 (and actually for almost=20
exactly 3 years), so we'd need to proceed with caution if we want to=20
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----