[3055] in linux-net channel archive
Re: Persistent SLIP statistics
daemon@ATHENA.MIT.EDU (Thomas Pawlikaniec)
Wed May 29 15:21:00 1996
Date: Wed, 29 May 1996 13:45:47 -0400 (EDT)
From: Thomas Pawlikaniec <neutrino@ee.mcgill.ca>
To: Michael Callahan <callahan@maths.ox.ac.uk>
cc: Paul Gortmaker <gpg109@rsphy6.anu.edu.au>, linux-net@vger.rutgers.edu
In-Reply-To: <Pine.3.89.9605291652.H29845-0100000@stlawrence.maths>
On Wed, 29 May 1996, Michael Callahan wrote:
> On Wed, 29 May 1996, Paul Gortmaker wrote:
>
> > I just noticed a minor side effect of the dynamic SLIP devices as
> > compared to the static sl0 -> sl3 found in a v1.2.x kernel.
> >
> > When the device goes down (even due to an inadvertent hangup followed
> > by an immediate redial), the statistics for that device are lost, and
> > reset to zero. While this doesn't upset me in any big way, the fact
> > remains that it is not consistent with the behaviour of any other
> > compiled in net device, such as ethernet cards. People like ISP's who
> > provide dedicated lines to clients might not like this.
>
> Well, it's not entirely inconsistent: PPP does the same thing. I _think_
> PPP has always done this.
>
> I can't remember if I thought about this at the time, but I think that my
> logic at the time might have been (would have been?) that the connections
> over a given PPP device may not, in general, have anything to do with one
> another. Therefore, it is probably more useful to know the statistics
> for _this_ connection, unconfused by the stats for previous connections.
Well, maybe a stupid suggestion, but given the pros and cons of both
cases, wouldn't it be possible to have _both_ ? Personally, I see
interest in both kinds of stats, if anyone could explain how one of
them could do the work of both, I vote for that one :-)
This assumes of course that the changes necessary to have both would not
hit performance, require code inconsistencies with other devices, etc
etc, etc...
Thomas Pawlikaniec
.sig coming Real Soon Now :-)
