Statistical Counters of intel 825xx network nic(from intel nic specification)
Tuesday, March 8, 2011 7:36:58 AM
The 8255x provides information for network management by providing on-chip statistical counters
that track a variety of events associated with both transmit and receive. The counters are updated
by the device when it completes the processing of a frame. For example, after the completion of
transmitting a frame on the link or when receiving a frame, the counter is updated. The Statistical
Counters are reported to the software on demand by issuing the Dump Statistical Counters
command or the Dump and Reset Statistical Counters command in the SCB CUC field. The
counters are internal to the device and are listed in the table below.
Byte Offset Device Statistic
0
Transmit good frames. This counter contains the number of frames
transmitted properly on the link. It is updated only after the actual
transmission on the link is completed and not when the frame was read from
memory as is done for the TxCB status.
4
Transmit maximum collisions (MAXCOL) errors. This counter contains
the number of frames that were not transmitted because they encountered
the configured maximum number of collisions. This counter should only
increment when the network is heavily saturated with traffic.
8
Transmit late collisions (LATECOL) errors. This counter contains the
number of frames that were not transmitted since they encountered a
collision outside of the normal collision window.
12
Transmit underrun errors. This counter contains the number of frames
that were either not transmitted or retransmitted due to a transmit DMA
underrun. If the device is configured to retransmit on underrun, this counter
may be updated multiple times for a single frame. Underruns occur due to a
lack of PCI bandwidth resulting in the internal transmit FIFO running dry
during the transmission of a frame.
16
Transmit lost carrier sense (CRS). This counter contains the number of
frames transmitted by the device despite the fact that it detected the deassertion
of CRS during the transmission.
20 Transmit deferred. This counter contains the number of frames that were
deferred before transmission due to activity on the link.
24 Transmit single collision. This counter contains the number of transmitted
frames that encountered only one collision.
28 Transmit multiple collisions. This counter contains the number of
transmitted frames that encountered more than one collision.
32
Transmit total collisions. This counter contains the total number of
collisions that were encountered while attempting to transmit. This count
includes late collisions and collisions from frames that encountered
maximum collisions.
36
Receive good frames. This counter contains the number of frames that
were received properly from the link. It is updated only after the actual
reception from the link is completed and all data bytes are stored in
memory.
40
Receive CRC errors. This counter contains the number of aligned frames
discarded out to a CRC error. This counter is updated, if needed, regardless
of the RU state. If the RX_ER pin is asserted during a receive frame, this
counter is incremented (only once per receive frame). This counter is
counter is mutually exclusive to the alignment errors and short frames
counters.
44
Receive alignment errors. This counter contains the number of frames
that are both misaligned (in other words, CRS de-asserts on a non-octet
boundary) and contain a CRC error. The counter is updated, if needed,
regardless of the RU state. This counter is mutually exclusive to the CRC
errors and short frames counters.
48
Receive resource errors. This counter contains the number of good
frames discarded due to unavailable resources. Frames intended for a host
whose RU is in the no resources state fall into this category. If the device is
configured to save bad frames and the status of the received frame
indicates that it is a bad frame, this counter is not updated unless the RU is
in a no resources state.
52
Receive overrun errors. This counter contains the number of frames
known to be lost because the internal receive FIFO overflowed (also known
as receive overrun). This can occur if the device is unable to get the
necessary bandwidth on the PCI (system) bus. If the overflow condition
persists for more than one frame, the frames that follow the first can also be
lost. However, since a lost frame indicator does not exist, these lost frames
may not be counted. A frame that was counted as an overrun will not be
counted in other error counters (short frames, CRC errors, or alignment
errors).
56
Receive collision detect (CDT) errors. This counter contains the number
of frames that encountered collisions during frame reception. This counter is
always 0 on the 82559.
60
Receive short frame errors. This counter contains the number of received
frames that are shorter than the minimum frame length. It is mutually
exclusive to the CRC errors and alignment errors counters and has a higher
priority (in other words, a short frame will always increment only the short
frames counter).
64
Flow control transmit pause. This counter contains the number of flow
control frames transmitted by the device. The count includes both the XOFF
frames transmitted and XON frames (in other words, PAUSE(0))
transmitted.
68
Flow control receive pause. This counter contains the number of flow
control frames received by the device. It includes both the XOFF frames
received and XON frames (PAUSE(0)) received.










