Network Support Encyclopedia 96-1

home *** CD-ROM | disk | FTP | other *** search

/ Network Support Encyclopedia 96-1 / novell-nsepro-1996-1-cd2.iso / download / netware / landr4.exe / STATS.DOC < prev next >

Wrap

Text File | 1993-10-06 | 63KB | 1,029 lines

LAN Driver Statistics Introduction By comparing information about the LAN drivers installed on the NetWare server, you can tell which cabling system is handling the most traffic. If errors occur frequently on a high-traffic system, you may want to switch some of the workstations on the busy system to a new cabling system or to a less busy cabling system. For information on viewing LAN driver statistics, see " Viewing LAN Driver Statistics" in Chapter 6 of Supervising the Network. The generic statistics common to most of the current drivers are listed in the following tables: Table B-1, "LAN Driver statistics common to all topologies," Table B-2, "Generic statistics for Ethernet drivers," Table B-3, "Generic statistics for RX-Net(tm) drivers," Table B-4, "Generic statistics for Token-ring drivers," Table B-5, "Generic statistics for baseband pcn2l drivers," CUSTOM STATISTICS vary, depending on the LAN driver installed. For statistical information about third-party drivers, check the documentation that comes with the driver. In most cases the programmer put this information in to give added statistical information that is in most cases only useful to the programmer. NOTE: If Card is not listed in the custom statistics section contact manufacturer/Driver writer of LAN Card in server for custom statistics documentation. Table B-6, "Custom statistics for Ethernet drivers," Table B-7, "Custom statistics for RX-Net(tm) drivers," Table B-8, "Custom statistics for Token-ring drivers," Table B-9, "Custom statistics for IBM baseband pcn2l drivers," ---------------------------------------------------------- Table B-1, "LAN Driver statistics common to all topologies," Statistics for LAN Drivers LAN Driver statistics Statistic Explanation Driver Name The driver name and parameters that correspond to the hardware settings on the network board. Version The current version of the driver. Node Address The station or node address of the network board in the NetWare server. Protocols The communication protocols bound to the driver with BIND. Network Address The network number assigned to the cabling system the LAN driver is operating on. Appears only if the IPX protocol has been bound to the board. Generic Statistics Total Packets Sent The number of packets sent from the NetWare server through this LAN driver. (By comparing this figure with the figures for other LAN drivers, you can see which driver is handling the most traffic.) (Maintained by TSM). Total Packets Received The number of packets received by the NetWare server since it was last booted (includes file service requests, packets routed to another network, and packets sent to other IPX sockets in the NetWare server). (Maintained by TSM). No ECB Available Count A counter that increments when a device sends a packet to your NetWare server, but no packet receive buffer is available. The NetWare server allocates more packet receive buffers after each incident until it reaches its maximum limit (configured with a SET parameter). If you are using an EISA or microchannel bus master board (such as the NE3200), you will probably need to increase both the minimum and maximum number of packet receive buffers. See the SET parameters. (Maintained by TSM). Send Packet Too Big Count A counter that increments when the NetWare server tries to transmit a packet that is too large for the hardware to handle. (Maintained by TSM). Reserved This field is reserved for use by the msm, but should be initialized to zero. Receive Packet Overflow Count The HSM (lan driver) may user this counter to indicate the number of times the adapter's receive buffers overflowed causing subsequent incoming packets to be discarded. (?? A counter that increments when the NetWare server receives a packet that is too big to store in a cache buffer. This happens rarely, unless you are running a software program that does not negotiate packet size. Contact the vender for an updated version of the software. ??). (Maintained by the HSM). Receive Packet Too Big Count The TSM increments this counter whenever a packet is received that is too large for the provided receive buffer(s). (Maintained by TSM). Receive Packet Too Small Count Some TSMs increment this counter if a packet is received that is too small for media definitions. Currently only the RX-Net TSM Maintains this counter. Send Packet Miscellaneous A counter that increments when Errors errors occur with send packets. (Maintained by HSM). Receive Packet Miscellaneous A counter that increments when Errors occur with receive packets. (Maintained by HSM). Send Packet Retry Count A counter that increments when the NetWare server tries to send a packet but fails because of a hardware error. Based on the number of retries in the retry counter, the NetWare server will try to send the packet until it is sent or the retry setting is reached. If you receive a large number of these errors, use LOAD LAN driver to increase the maximum retry count, or check the cabling and workstation hardware. (Maintained by HSM). Checksum Errors The HSM may use this counter to increment when the checksum byte at the end of the packet does not match the sum of the bytes contained in the packet. This indicates a data error. (Maintained by HSM). Hardware Receive Mismatch count A counter that increments when the packet length received by the hardware and the length specified by the packet do not match. Currently only the Ethernet TSM maintains this counter. (Maintained by the TSM). Total Send OK Byte Count Low The number of bytes including low level headers successfully transmitted. (Maintained by the MSM). Total Send OK Byte Count High Upper 32-bits of the Total Send OK Byte Count Low. Basically this will increment to 1 when the above counter reaches 4 gigabytes (Maintained by the MSM). Total Receive OK Byte Count Low The number of bytes including low level headers successfully received. (maintained by the MSM). Total Receive OK Byte Count High Upper 32-bits of the Total Receive OK Byte Count Low. Basically this will increment to 1 when the above counter reaches 4 gigabytes. (maintained by the MSM). Total Group Address Send Count The number of packets transmitted with a group or multicast destination address. (maintained by MSM). Total Group Address Receive The number of packets received Count with a group or multicast destination address. (maintained by MSM). Adapter Reset Count The number of times the adapter was reset because of internal failures or other calls to the Driver Reset routine. (maintained by the HSM). Adapter Operating Time Stamp The time stamp indicating when the adapter last changed operational state (such as load, shutdown, or reset). (Maintained by the MSM). Adapter Queue Depth The number of transmit packets (transmit ECBs) that are queued for the adapter. This is an indication of throughput overload on transmits. (maintained by the TSM). --------------------------------------------------------------- Table B-2, "Generic statistics for Ethernet drivers," Generic statistics for Ethernet drivers (Using ETHERTSM.NLM). Statistic Explanation Send OK Single Collision Count The number of frames involved in a single collision but are subsequently transmitted successfully. When the Ethernet controller detects a collision, it backs off and then will retry the transmission. Send OK Multiple Collision Count The number of frames involved in more than one collision but transmitted successfully. This happens when the Ethernet controller had to back off more than once due to collisions. See also TxAbortExcessCollisions. Send OK But Deferred The number of frames whose transmission was delayed because of a busy medium. This happens when another station is transmitting on the wire when the adapter receives the command to transmit a packet. Send Abort From Late Collision The number of transmits that had a collision occur after 512 bits of the packet had been transmitted. This can be caused by faulty adapters, faulty network equipment, cable lengths not to specifications, or faulty termination. Send Abort From Excess The number of transmits that were Collisions aborted because of too many collisions. This usually indicates that a board in the network is bad or jabbering. This condition could also possibly occur in very heavy traffic conditions. Send Abort From Carrier Sense The number of transmits aborted because of loss of carrier sense while transmitting without any collisions occurring. This usually indicates a bad board in the network (shorting the cable), faulty cable, un-terminated cable or faulty repeater. Send Abort From Excessive The number of transmits aborted Deferral because of excessive deferrals. This is usually caused by a faulty adapter or repeater in the network that is jabbering on the wire. This condition could also possibly occur in very heavy traffic conditions. Receive Abort From Bad Frame The number of received frames that Alignment were misaligned. This occurs when the number of octets in the frame is not correct or it does not pass the FCS check. These bad packets are usually caused by a faulty adapter or repeater in the system. They can also be caused by a collision. ------------------------------------------------------- Table B-3, "Generic statistics for RX-Net(tm) drivers," Generic statistics for RX-Net(tm) drivers (Using RXNETTSM.NLM). Statistic Explanation No Response to Free Buffer A counter that increments each Enquiry time there is no response from the receiving node to Free Buffer Enquiry. Network Reconfiguration Count A counter that increments each time a Network Reconfiguration occurs. Invalid Split Flag in Packet A counter that increments each Fragment time the Split Flag in the packet fragment is not the value expected. Packet fragments received out of order can cause this value to increase. Orphan Packet Fragment Count A counter that increments each time a packet fragment is received that is not a part of a previously received packet and therefore cannot be appended. Receive Packet Timeout A counter that increments each time a received packet times out while waiting for the rest of the packet fragments to arrive. Free Buffer Enquiry NAK Timeout A counter that increments each time a transmit packet times out while waiting for an acknowledgment to a Free Buffer Enquiry from the receiving node. Total Send Packet Fragments OK A counter that increments each time a packet fragment is sent successfully. This number will be high because packets are made up of multiple fragments. For example a 4K packet is actually eight 512 byte packet fragments. Total Receive Packet Fragments A counter that increments each OK time a packet fragment is received successfully. This number will be high because packets are made up of multiple fragments. For example a 4K packet is actually eight 512 byte packet fragments. --------------------------------------------- Table B-4, "Generic statistics for Token-ring drivers," Generic statistics for TOKEN-RING drivers (Using TOKENTSM.NLM). Statistic Explanation AC Error Counter This counter increments when a ring station receives a "Standby Monitor Present" MAC frame with the A/C bits in the Frame Status field equal to zero without first receiving an "Active Monitor Present" MAC frame. Abort Delimiter This counter increments when a ring station transmits an abort delimiter. An abort delimiter is transmitted when a ring station receives a frame in which the token bit of the access control field is set to show "Token" and not "Frame." A ring station can also transmit an abort delimiter in an internal hardware error has occurred. Burst Error Counter This counter increments when a ring station detects the absence of "five half-bit times" (a burst-five error). Other stations will detect a burst- four error followed by idles. Frame Copied Error Counter This counter increments when a ring station recognizes (receives or repeats) a frame addressed to its specific address and detects that the FS field A bits are set to 1 indicating a possible line hit or a duplicate address. Frequency Error Counter This counter is incremented when the frequency of the incoming signal differs from the expected frequency by more than that specified in Section 7 (IEEE Std 802.5-1989). Internal Error Counter This counts the times a ring station has a recoverable internal error, which means a ring station is probably marginal. Last Ring Status This code changes each time the ring status changes. Status codes, are reported by the physical hardware. See the IBM Token-Ring Network Architecture Reference for the Status Code, Function and Meaning. Line Error Counter This counter increments when a frame or token is repeated by the ring station. A frame is repeated when a "Frame Check Sequence" error occurs or a code violation exists between the starting and ending delimiters of the frame. Lost Frame Counter This counts instances when a ring station transmits a frame that does not return to the station. The active monitor sends a new token. Token Error Counter This counter is incremented when a station acting as the active monitor recognizes an error condition that needs a token transmitted. This occurs when the TVX timer expires. Up Stream Node High Dword: The first 8 digits of the Up Stream node address of next node up stream on the ring. Up Stream Node Low Dword: The next 4 digits of the Up Stream node address of next node up stream on the ring. Last Ring ID This contains the value of the local ring. Last Beacon Type This contains the value of the last beacon type. --------------------------------------------- Table B-5, "Generic statistics for baseband pcn2l drivers," Generic statistics for PCN2L IBM BASEBAND drivers (Using PCN2LTSM.NLM). Statistic Explanation Send OK Single Collision Count The number of frames involved in a single collision but subsequently transmitted successfully. Send OK Multiple Collision Count The number of frames involved in more than one collision but subsequently transmitted successfully. Send OK But Deferred The number of frames whose transmission was delayed because of a busy medium. This happens when another station is transmitting on the wire when the adapter receives the command to transmit a packet. Send Abort From Excess The number of transmits that were Collisions aborted because of too many collisions. This is usually caused by a faulty adapter in the system. It can also occur under very heavy traffic conditions. Send Abort From Carrier Sense The number of transmits aborted because of loss of carrier sense while transmitting any collisions. This is usually caused by a faulty adapter in the system, faulty cabling, an unterminated cable, or a faulty repeater. Receive Abort From Bad Frame The number of received frames that Alignment were misaligned. These bad packets are usually caused by a faulty adapter or repeater in the system. They can also be caused by a collision. ----------------------------------------------------- Table B-6, "Custom statistics for Ethernet drivers," NE2000.LAN, NE2.LAN, and NE2_32.LAN, NE1000.LAN UnderrunErrorCount This counter increments when the RAM buffer on the network board is full; the board cannot accept any more packets until the RAM buffer is cleared. TransmitTimeoutCount This counter increments when a network board interrupts the file server with the message that the "send bit" is lost. This is a hardware problem caused by faulty cabling, a bad network board, or a missing terminator. RxPagingErrorCount This is a count of the errors that occur when internal buffers on the card are corrupted. ReceiveFIFOOverrunErrorCount This counter increments when an incoming packet causes an overflow because FIFO was not serviced. ReceiverMissedPacketCount This counter increments when a packet is sent to a network board that cannot accept the packet because all its receive buffers are full. GotNothingCount This counter increments when the file server receives an interrupt from a network board that is not transmitting or receiving anything. This is not serious. UnsupportedFramePacketCount This counter increments when a packet is received by the lan driver with a frame type that hasn't been loaded for the given card. UnsupportedMulticastCount This counter increments for each multicast packet received by the card that is not registered with the driver. BackToBackSendCount This counter increments each time the driver can buffer a send packet onto the network board while the board is sending a previous buffer. Use this counter to track congestion on the network board. See also "EnqueuedSendsCount". EnqueuedSendsCount This counter increments when the driver is unable to transmit a packet and must put the packet in a que until the transmitter is available. Use the counter to track congestion on the network board. See also "BackToBack SendCount". In32BitModeCount (NE1000 only) This counter increments if a network board is ever found in 32- bit mode. (Currently, workstations run in 8-bit mode.) Occasionally, older ne1000 boards have bad ships that make the boards go into 32-bit mode. If you ever see this counter incremented, you probably have one of those older boards on the network. NE2100.LAN, NE1500T.LAN HeartBeatError This counter increments when there is a collision after transmission. This function is also known as heartbeat or SQE (Signal Quality Error) test. This counter would indicate a hardware problem. MemoryTimeout This counter increments when there is contention on the bus. This counter incrementing is indicative of a bus contention problem. If this counter is incrementing then more than likely you have either have multiple NE2100 or NE1500T cards in the server or another Bus Mastering Device in the server (ie. disk channel). TxBabblingError This counter increments when there is excessive length in the transmit buffer. It will increment after 1519 data bytes have been transmitted from the buffer. It indicates that the transmitter has been on the channel longer than the time required to send the maximum length packet. This counter would indicate a hardware NIC card problem in the server. TxUnderflowError This counter increments when something else on the bus takes control of the bus while the LAN driver is putting the data on the wire. The packet would then have to be retransmitted. TXBufferError This counter increments when there is a problem with the transmit buffer. This counter will also commonly increment when TxUnderflowError increments. This counter could be indicative of hardware problem in the server. RxECBsOver16MegCount This counter will increment when a TxECBsOver16MegCount transmit or receive occurs and the driver has had to use the reserved buffers below 16 meg double buffer the ECB because the card can't access above 16 Meg of memory (physical limitation). The NE1500T and NE2100 cards are not able to access memory above 16 MB. Therefore, if the operating system issues an Event Control Block (ECB) with an address above 16MB of memory, the board uses some of the reserved buffers below 16MB to queue the request. These are not errors. They are only keeping track of how many ECBs were redirected to the buffers below 16MB. In many cases, this counter can be as high as the total packets sent and received. Because of this double buffering that occurs it does cause a performance hit. Any board that is busmastering or uses DMA that is not a 32 bit adapter will potentially experience a performance hit if you have more than 16 MB of ram. PacketUsed2ECBs This counter will increment if the Server Maximum Physical Receive Packet Size is set to 1514 (default for 3.11 servers, it can be changed in the STARTUP.NCF), and we need an extra 4 bytes to receive a near full size packet to include the CRC on the end of the packet we will use 2 ECBs. This is a slight performance hit to use 2 ECBs instead of one but will function properly. NOTE: Netware 3.12 and 4.X default the Maximum Physical Receive Packet Size to 4202. NE3200.LAN Transmit Retry Failure: This counter increments when the driver is unable to transmit a packet a reset number of times. This may indicate a hardware problem. Tx Clear To Sends Errors: Attempt to catch an 82586 errata. There are some conditions when the clear to send signal from the 82586 chip is incorrect. This indicates the number of times the corrective code on the adapter was executed to work around this condition in the 82586. Tx DMA Underrun Errors: Attempt to catch an 82586 errata. This can occur when contention between the BMIC, 80186 and 82586 occurs on the adapter. The 82586 thinks it did not get all of the packet for transmission. The transmit operation must be retried in this case. This indicates the number of times the corrective code on the adapter was executed to work around this condition. Rx DMA Overrun Errors: Attempt to catch an 82586 errata. If two packets are received back to back at near the minimum ethernet inter-frame spacing of 9.6 microseconds then the chip may report an overrun. If so, the frames are lost by the chip and the source will have to re-transmit. Rx Packet Slide Errors: Attempt to catch an 82586 anomaly. In some strange conditions, the 82586 may get off by two bytes in the receive packet descriptors. This number indicates the number of times this condition occurred. The sending station must retransmit the packet in this case. Rx Dummy RCB Used Errors: Attempt to catch an 82586 errata. In some cases, the 82586 may attempt to receive data into a non-existent receive buffer off the end of its receive buffer list. To catch for this condition and avoid internal data corruption, a dummy receive buffer is added to the end of the list. This variable counts the number of times the 82586 attempted to write into the dummy buffer. Internal Adapter Reset: This is count of the number of resets in that occurred on the adapter (by the 80186) due to failures on the adapter. This counter increments when the software corrects itself for minor problems or if the card gets into an unknown state. This counter commonly increments. Under normal conditions, more of these errors should occur during idle time than when the driver is busy. For this counter to warn you of potential hardware problems, you must receive thousands of these errors when the network is busy. Mondo Fragment Length Errors: An NLM on the Server has passed the NE3200 driver an ECB whose logical memory address we couldn't change to a physical memory address. You should check other NLMs on the system and upgrade them. If you are still experiencing problems identify which NLM is causing the problem and contact the third party manufacturer of the NLM. Polling Timeout: The adapters request was put on the que but because the server was busy it was not able to be serviced within 800 nanoseconds (default). If this occurs the adapter will then fire an interrupt to get serviced. Reset Because Hardware Died Errors: If the adapter gets in an unknown state or stops transmitting on the host side the driver will increment this counter will reset/restart the adapter. Number Of Interrupts Fired: This counter increments each time the adapter had to fire an interrupt to service a request because the polled request wasn't serviced. NE32HUB.LAN FIFOUnderRunCount This counter increments usually during high utilization or high BUS usage and we are unable to send the packet. This should occur rarely. ByteCountMismatchCount This counter increments when the transmit packet size is not = to sum of fragments passed to the SONIC chip on board. This should occur rarely. HardTransmitErrorCount This counter increments when a CRC, Excessive Deferral, ByteCount MismatchCount, or FIFOUnderRunCount occurs on a transmit. This is more of a general transmit error counter. TransmitCollisionsCount This counter increments when the card can't transmit on the wire. If the card takes 5 times to get the packet transmitted this counter will be incremented by 4. OutOfWindowCollisionCount This counter increments when an illegal collision occurs. The collision should normally be during the preamble. If the collision incorrectly occurs after the preamble this counter will increment. This should be rare. CRCErrorCount This counter increments when a packet is received by the card with a bad CRC. FIFOOverrunCount This counter increments when a packet is received and there are errors in the packet. The driver looks at the FIFO overrun counter to determine if there are errors. The packet is not received if there are errors. RDAExhaustCount This counter increments when the driver can't take the data out of the buffer fast enough to process it and the Receive Descriptor Area is overflowed. This shouldn't happen very often but is more likely under high utilization. RRAExhaustCount This counter increments when the driver can't take the data out of the buffer fast enough to process it and the Receive Resource Area is overflowed. This shouldn't happen very often but is more likely under high utilization. RBAExceedCount This counter increments when the driver can't take the data out of the buffer fast enough to process it and the Receive Buffer Area is overflowed. This shouldn't happen very often but is more likely under high utilization. FlagFoundCount This counter increments when the RIC chip on the card reports an error such as (Jabber, Out of window Collision etc.) PacketsCompressedCount This counter increments when the driver is in promiscuous mode and is looking at every packet. To get the management information efficiently the driver only copies the first 50 bytes of the packet into the buffer and then adds on the 7 bytes of management information on the end of the packet. This occurs only on the packets that are not destined for the server when the driver is loaded with PCOMP=ENABLE (default). RICAddressWasInvalidCount This counter increments when the RIC address was corrupt on a receive management packet. The driver expects this number to be correct. That is why the driver checks the RIC address. TxTimeOutCount This counter increments when a transmit doesn't occur in 2 seconds. Port0ErrorCount This counter increments when the port address is set to 0. The port address should always be between 1 and 12. This will not occur frequently. PortBigErrorCount This counter increments when the port address is above 13. The port address should always be between 1 and 12. This will not occur frequently. ValidCRCCount This counter increments when the Management Information overlaying the CRC is correct. It should be incorrect. This should happen rarely. ------------------------------------------------------ Table B-7, "Custom statistics for RX-Net(tm) drivers," Custom statistics for Arcnet server driver: TRXNET.LAN Statistic Explanation NONE ------------------------------------------------------ Table B-8, "Custom statistics for Token-ring drivers," Custom statistics for token-ring cards: TOKEN.LAN, NTR2000.LAN Bad Correlator Count This counter increments when a network board responds with a request for data from the file server that the file server does not have. The ECB or some other code may be corrupted. Eventually, this type of error will down the server. If this counter is non-zero, you should try to find the software that is corrupting the data. Unknown ARB requests This counts bad ARBs (Adapter Request Blocks). Normally the network board (adapter) uses one of four known commands to communicate with the driver. If a network board sends a command that is NOT one of the four, the driver does not recognize the request. This is not a catastrophic error. Sometimes old adapters send bad ARB requests because of software problems resident on the board. NetWare responds to the network board so that the board will not hang. TOKENDMA.LAN MicroChannel Error Count: Adapter ran into a problem transmitting on the Bus. The Adapter Interrupt occurred from the firmware on the card. ECBs Over 16Meg: The number of packets received that had to use an ECB over 16 meg. This number should only increment when using more than 16 meg of ram in the F/S. DMA Bus Errors Count: This counter is incremented when a DMA transfer completes with a bus error. If this increments it could be indicative of a hardware problem. DMA Parity Errors Count: This counter is incremented when a DMA transfer completes with a parity error. If this increments it could be indicative of a hardware problem. Command Reject Count: This counter is incremented when the Driver sends a command to the card and the command is either invalid or the card is still busy processing the previous command. This number should be 0 or low. Tx Timeout Count: This counter is incremented and the adapter is reset if 2 seconds elapses and the driver hasn't heard back from the firmware that the transmit was or wasn't successful. This counter shows the driver successfully recovering from the lost hardware transmit. It is OK to see this number increment. Transmit Late Count: This counter will increment when the driver thought that the card was transmitting more than it really was because of what was reported by the firmware. The data that wasn't transmitted will then be sent in the next packet. This is a latency type of issue. You will likely see more of these errors on a busier network. Transmit Defragment Count: The IBM Token-Ring DMA LAN boards are not able to access memory above 16 MB. Therefore, if the operating system issues an Event Control Block (ECB) with an address above 16MB of memory, the board uses some of the reserved buffers below 16MB to queue the request. These are not errors. They are only keeping track of how many ECBs were redirected to the buffers below 16MB. In many cases, this counter can be as high as the total packets sent and received. Because of this double buffering that occurs it does cause a performance hit. Any board that is busmastering or uses DMA that is not a 32 bit adapter will potentially experience a performance hit if you have more than 16 MB of ram. ------------------------------------------ Table B-9, "Custom statistics for IBM baseband pcn2l drivers," Custom statistics for PCN2L IBM baseband server driver: PCN2L.LAN HotCarrierInterruptCount This counter increments when the board detects a carrier longer than expected without a transmit. This Generally indicates that some board on the network has failed or is starting to go bad. No82588InterruptCount This counter increments each time it receives an interrupt from the card but not the 82588 chip. This should never happen. WeirdInterruptCount This counter increments when the file server has received an interrupt from the card, but the card claims not to have sent one. This should never happen. BadTransmitCompleteInterruptCount This counter increments for each complete transmission with no transmit active. HardTransmitErrorCount This counter increments when a transmit fails and the driver retries the transmit. GotNothingCount This counter increments when the driver receives an interrupt from the card indicating that it has completed a receive but there is no data in the card's receive buffer. This is not serious. ReceiveUnderrunErrorCount This counter increments when the driver finds less data in the card's buffer than the card said was there. ReceivedShortPacketCount This counter increments when a packet of less than 17 bytes is received. BadReceiveConditionCodeCount This counter increments when the buffer is flushed because the card hasn't received the incoming packets properly.