Re: ifconfig v2

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> Personally, I don't think the traffic-rate stuff belongs in the
>> kernel.  I'd prefer to see that implemented in netstat by sampling
>> stats twice with a measured delay and doing the arithmetic there.
>> [...]  "Mechanism, not policy."
> Uh, "load average"?

Good point.

Given the decaying-average nature of the load average, it requires
enough state that it has to either be in the kernel or be in a
long-running daemon (or, perhaps, a frequently-started but very
short-running daemon which keeps state elsewhere, like a file).  I'm
not sure which design I prefer (though admittedly the in-kernel one has
the advantage of already existing).

My impression is that the interface statistics you're looking for are
not decaying averages, so that concern doesn't apply.  But even if
that's correct...

> An example "show interface" output from a Cisco route server:

> Ethernet1/0 is up, line protocol is up 
[...]
>   5 minute input rate 2000 bits/sec, 3 packets/sec
>   5 minute output rate 2000 bits/sec, 3 packets/sec

...five minutes is long enough that it's not practical to do a "sample
twice with a delay" when the statistic is requested.  However, it is
practical to do something like sample every minute and use historical
data; on the machines where I care about such things I sample every
five minutes (driven off cron) and save the data.

Is the Cisco data "the five minutes before the query time"?  Or is it
"some recent five minute interval", such as the interval between the
most recent two times floor(uptime / five minutes) changed?  Or some
mix, such as "the five minutes before the most recent time
floor(uptime / one second) changed"?

I'm not sure whether I think the benefits of doing it in the kernel
instead outweigh the costs.  I suppose it depends at least in part on
what the costs are, which depends on things such as the answers to the
previous paragraph.

Also, Cisco's raison d'etre is such things; they can afford to dedicate
more resources (here mostly meaning RAM) to such things than a
general-purpose OS might want to.  Or perhaps a kernel option could
control it, so that high-RAM machines can get detailed stats without
crippling low-RAM machines.

Or, modern NetBSD being what it is, perhaps it should just go in;
people using machines with less than a gig (or whatever) of spare RAM
can always just run something else.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B