Re: ifconfig v2

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

On Jun 14,  1:07pm, Mouse wrote:
}
} >> 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.

     Early Cisco routers were very much starved for RAM.  Even
modern ones may not have a lot of RAM for administrative stuff
since it may be wanted for things like holding the OS (early routers
ran the OS from flash memory, modern ones keep compressed images
in flash memory), holding routing tables, etc.

}-- End of excerpt from Mouse