0

When we test the eth card with ethtool -S we get rx_missed_errors: 4649.

What is the meaning of rx_missed_errors? Is it a major problem?

 rx_over_errors: 0
 rx_crc_errors: 0
 rx_frame_errors: 0
 rx_fifo_errors: 0
 rx_missed_errors: 4649
 tx_aborted_errors: 0
 tx_carrier_errors: 0
 tx_fifo_errors: 0
 tx_heartbeat_errors: 0
 rx_long_length_errors: 0
 rx_short_length_errors: 0
 rx_csum_offload_errors: 




ethtool -g eth847
Ring parameters for eth847:
Pre-set maximums:
RX:             8192
RX Mini:        0
RX Jumbo:       0
TX:             8192
Current hardware settings:
RX:             1024
RX Mini:        0
RX Jumbo:       0
TX:             1024
yael
  • 12,598
  • 51
  • 169
  • 303
  • Note that we already have https://unix.stackexchange.com/questions/205141/ and https://unix.stackexchange.com/questions/184604/ . – JdeBP Mar 05 '19 at 08:56

1 Answers1

3

The exact meaning of rx_missed_errors depends on the Ethernet driver in use, but it’s supposed to count missed packets on the receiver side, i.e. packets which the NIC received but had to drop because they couldn’t be stored or processed — typically, because the FIFO they would have gone to was full.

Whether it’s a major problem depends on the traffic being dropped. In most cases, dropped packets will end up retransmitted if necessary, by one layer of the stack or another.

If the drops are bursty, you could try increasing the buffers (if your NIC allows you to): check the maximum setting with ethtool -g, and set it with ethtool -G. In your case, you can set the receive and transmit rings to anything up to 8192:

ethtool -G eth847 rx 8192

It’s not necessarily a good idea to set the buffer to the maximum value immediately: larger buffers can result in increased latency. I suggest increasing the buffers progressively, and watching the error rate to see how it evolves.

Stephen Kitt
  • 411,918
  • 54
  • 1,065
  • 1,164