Should I be concerned about a 0.05% packet drop rate?

Environment

• Red Hat Enterprise Linux (RHEL)

Issue

The network interface reports a number of packet drops. What should I do about it?

Resolution

Packet drops in a network are normal and expected.

One of TCP's main functions is to preserve a reliable data stream for applications by identifying and retrying any lost packets. It is normal operation for an underlying network to lose packets, for many different reasons, and for TCP be used and to hide this fact from application layers. Applications using unreliable transports (the major one being UDP) are expected to not care about the unreliability of the network. Applications which do care should use a reliable transport, eg. TCP (or more recently, SCTP) or implement their own reliability mechanisms.

The only impact of packet loss in the underlying network (which includes the device-drivers and lower network layer code which is counting the drops you are seeing) is a reduction in performance from the peak network speed. The reduction is dependent, non-linearly, on the packet drop ratio, and also on the traffic type. For bulk transfers (such as file-transfer) over TCP a drop ratio of under 0.1% results in a very small reduction in throughput -- assuming that the Select Acknowledgement (SACK) TCP option is enabled on both systems. If SACK is disabled on either system there will be a measurable reduction in throughput if the drop rate exceeds 0.001%. On the other hand, thin stream traffic, where there is often no outstanding data for the transmitter to send, will be affected more as the need to retry lost packets will only be noticed after a time out rather than being detectable when data arrives out-of-order. Examples of thin-stream traffic include request-response and interactive connections.

Diagnostic Steps

Use the "ip -s link" command to compare the number of drops with the number of packets. You can also use the change in "TcpOutSegs" and "TcpRetransSegs" from "nstat -a" to calculate a retransmission rate on the sender. Note however that this will reflect the entire system not just one TCP stream.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.