HANK@BARILVM.BITNET (Hank Nussbacher) (06/17/90)
How can I see what percentage of use my cisco is using for routing Decnet traffic as opposed to IP traffic as opposed to Appletalk traffic? I would also like to see how much of the processor is needed to route 1000 IP packets and what effect routing 1000 DECNET packets would have on the routing of the Ip packets. I'm sure the sho process will help me but the manual is skimpy in explaining the full meaning of all the fields. The sho ip accounting also helps but without a sho decnet accounting I get a very poor idea of how much of the cisco is truly being used for Decnet. Thanks, Hank
hedrick@cs.rutgers.edu (06/18/90)
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.