Ref: 99980001
Title: Interpreting Network Management Statistics
Date: 9/1/87

Copyright 3Com Corporation, 1991.  All rights reserved.

Interpreting Network Management Statistics

Datalink statistics should be monitored carefully for tracking
overall network traffic.  The statistics for the busiest minutes
may be set to zero by using the ZeroStats command, providing a
starting point for analysis of these reports.

Use the following guidelines to interpret network management
reports:

1.  The following table lists guidelines for interpreting CPU and
BUFfer usage in the busiest sample, busiest minutes, hour
average, and 24-hour average reports.

Report           CPU usage               BUFfer usage

Busiest Sample   up to 80% is normal;    up to 80% is normal;
                 can be 100% without     100% may indicate
                 adverse affects.        overload-call Bridge
                                         Technical Support

Busiest Minutes  100% may indicate       up to 75% is normal;
                 overload-call Bridge    100% may indicate
                 Technical Support*      overload-call Bridge
                                         Technical Support

Hour Average     up to 70% is normal;    up to 75% is normal;
                 90% may indicate        100% may indicate
                 overload-call Bridge    overload-call Bridge
                 Technical Support       Technical Support

24-Hour Average  70% may indicate        up to 45% is normal;
                 overload-call Bridge    70% may indicate
                 Technical Support*      overload-call Bridge
                                         Technical Support

       *100% CPU usage on a CS/1-HSM or IB/1-FT is normal.

2.  Error rates on fiber optic and broadband networks tend to be
higher than those on Ethernet baseband networks.  This is normal.

3.  For the hour average, accumulated PORT errors may indicate
cable shielding problems or the wrong interfacr type.

4.  If the number of accumulated disk errors (AcuDskEr) is
persistently above 0, a problem with the diskette or drive is
indicated.  Clean the disk drive head and replace the system
diskette.  If the problem persists, the drive may have to be
replaced.

5.  XMT or RCV errors may indicate a hardware problem with the GS/
3 or modem.

6.  Persistent parity errors (ERR) may indicate a problem with
the hardware at the terminal or server end of the connection.  A
port with improper parity parameter settings would generate an
extremely high number of errors; this problem would probably be
indicated by an unusable terminal before being noticed in a
network management report.

7.  The network should not generate any packet-too-short or
packet-too-long errors.  If the server consistently detects
packet-too-long errors, the device that is generating the bad
packets is deviating from network protocol standards.

8.  The number of CRC, alignment, and packet-too-short or packet-
too-long errors is a function of the number of stations and the
traffice load on the network.  A sharp increase in the number of
CRC, alignment, or packet-too-short errors indicates a network
problem, such as a bad transceiver, bad controller, or cable
probelm.

9.  The number of collisions is a function of the number of
stations and the traffic load on the network.

10. A problem is indicated if the number of collisions suddenly
increases markedly.

11. Appearance of a negative number in any statistics reports
indicates an extremely large number of errors (over 32,000) and
warrants immediate investigation and corrective action.

The statistics shown in the 24-Hour Average report are
particularly useful when compared with the following statistics:

*  The daily Datalink statistics in the 24-Hour Average report on
other Communications Servers.  This comparision is useful for
problem isolation:  a wide discrepancy among different servers on
the same network may point to a network interface problem.

*  Datalink statistics in the other reports for the same server.
If the accumulated Datalink errors are high, the other reports
can help pinpoint when the network disturbance occurred.

The minutes statistic is the most useful for troubleshooting.
Using the ZeroStats command, you can immediately verify whether a
problem has been corrected.  For example, a network report may
indicate 4 CRCs, 4 ALNs, 4 COLLs per minute.  After finding and
correcting the problem, you can use the ZeroStats command on all
servers; one minute later you can use the new statistics to
verify correction of the problem.

Acceptable error rates are relative to the size and complexity of
your network.
