Subject: Re: CVS commit: src/sbin/ifconfig
To: Manuel Bouyer <bouyer@antioche.eu.org>
From: Greg A. Woods <woods@weird.com>
List: tech-misc
Date: 04/13/2003 14:12:03
[ On Sunday, April 13, 2003 at 16:09:05 (+0200), Manuel Bouyer wrote: ]
> Subject: Re: CVS commit: src/sbin/ifconfig
>
> On Sat, Apr 12, 2003 at 06:30:20PM -0400, John Hawkinson wrote:
> >
> > Why is it necessary to support clearing counters at all?
> > It seems to add a lot of pain for not a lot of benefit.
>
> I (and others) find it a usefull feature. Maybe I work too much with
> cisco switches :)
What, exactly, is the technical usefulness of being able to zero
counters?
So far the only really good reason I've seen mentioned is that it's
easier for most humans to deal with smaller numbers when looking at
counters, especially when trying to understand the delta relationships
between several such counters.
If that's the only real reason for wanting to be able to zero counters
then that's not really any reason at all -- rather it's just an feature
requirement for the tool used to retrieve and view those counter values,
and the solution already exists, in netstat with '-w wait' (and could be
augmented with '-c count' ala the other *stat programs).
Note too that Cisco IOS usually deals with counters in exactly the way
Bill suggested too, IIUC. They never zero the real counter, but just
set some presentation offset for the CLI user.
Now I think the command-line tools should always show the real counter
values, not the delta from the last "reset" point, and that a special
option be required to show the latter. However this brings us back to
the question of why '-w wait' isn't a sufficient and complete
replacement for the combination of marking the "reset" point and showing
the delta from that "reset" point, since it provides almost exactly the
same functionality, especially for any CLI that provides decent job
control features.
I.e. why does the reset point have to be stored in the kernel?
--
Greg A. Woods
+1 416 218-0098; <g.a.woods@ieee.org>; <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>