Subject: Re: Resetting ip, icmp etc statistics
To: Havard Eidnes <>
From: Bill Studenmund <>
List: tech-net
Date: 03/31/2006 23:24:03
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

> I can understand the convenience to those who don't run SNMP and
> who just fixed a problem and want to se "what does it look like
> that", and not having to reboot to reset the statistics.
> "Real" routers where statistics is normally collected using SNMP
> and who also have this "clear counters" function do this IMO the
> right way, i.e. by checkpointing the base level for the counters
> and only displaying the difference compared to this base level
> when commands equivalent to "netstat" are run.
> I'm not sure what I think of the "add a sysctl to prevent
> accidental resetting of the counters" idea.  As has been noted it
> would only prevent accidentall resetting, and is more of a
> stopgap because people for some reason or other balk at the
> "checkpoint base level to diff against for the user interface"
> solution.  "Bloat" might be an argument against this solution.

Well, I don't see the sysctl as a stopgap. :-)

really only permits you one level of checkpointing, for a lot of work. =20
administrators about all these new counters. And we only get one

All that work for one checkpoint.

It doesn't scale well. Say one administrator wants to reset the counters=20
to measure something. That works, unless another administrator had already=
reset them and was still trying to track something else. Then that=20
administrator has lost. :-(

Part of my reason for suggesting the sysctl is that I really see the
problem as either you care about monotonicity (you have SNMP daemons,
etc.) or you don't. If you don't care, you don't care. There is no need
for worrying about monotonic counters, since by definition, they don't
matter. :-)

If you do care, then yes, you really need to make it so folks can't reset=
the counters. The sysctl is one way. If cooperative control isn't enough,=
then when we get something like kauth's bitmask for controlling things, we=
can add a bit to freeze the sysctl; if it needs locking, we'll lock it.

But if you care, you care because you've set up tools that monitor these=20
counters. If you've set up some tools, is it really that much to expect=20
you to add a few more? I could be wrong, but, given the diversity of=20
sysadmin tools I've seen, I find it hard to believe that someone hasn't=20
already come up with a tool that will let you check point a value and=20
watch it grow with time. i.e. something that will read the value, put it=20
in a file, then subtract that value in the future for reporting=20

Given such a tool, checkpoint in userland. Let the kernel keep one=20
counter, and leave checkpointing to the data gathering tools. :-)

Thus one counter really can serve us well.=20

Take care,


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.3 (NetBSD)