Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!ucsd!ames!ncar!boulder!daemon
From: hedrick@cs.rutgers.edu
Newsgroups: comp.dcom.sys.cisco
Subject: Re:  How do I measure what my cisco is doing?
Message-ID: <22358@boulder.Colorado.EDU>
Date: 18 Jun 90 01:39:36 GMT
Sender: daemon@boulder.Colorado.EDU
Lines: 29

You can tell how many IP packets and DECnet packets are forwarded, by
using "show ip traffic" and "show decnet traffic".  This will give a
reasonable idea of relative usage.  However there's no simple way to
show the processor overhead per packet.  At least if you have MCI's,
the switching is done at interrupt level, and involves so little CPU
time that measuring it would be sort of difficult.  It's easier to
measure routing overhead, by doing "show process" and looking at the
IGRP process and the DECnet routing process.

There are also IP and DECnet input processes, but the problem is that
they show only things that aren't handled by fast-switching, and on an
MCI you'd hope that most packets would be fast-switched.  I think the
theory is that with fast switching, it's really unlikely that you'll
run out of CPU due to switching, barring some really pathological
network setup.  

In "show process" the relevant number is "Runtime (ms)", which show
how many milliseconds the process has run.  

By the way, even if you could see CPU time taken by switching, it's
unclear what you would do with it.  The problem is that for most
networks, traffic is very "bursty".  So the fact that only 10% of your
CPU is being used may be meaningless.  That's really an average usage
over some long time.  What really makes demands on your system is when
you get a burst of traffic.  It's going to be very hard to measure
exactly what is going on.  These are the kinds of considerations that
lead people to ask for gateways that can switch the whole bandwidth of
an Ethernet, even though frankly I think it's silly.  The problem is
that it's very hard to define or measure what you actually need.