A Linux file server with a 10 Gb NIC never transfers faster than about 90 MB/s and users report occasional stalls. Which `ethtool` and `ip` commands tell you whether the link negotiated the wrong speed or the interface is discarding frames, and how do you read their output?

## Separate the two questions A slow interface has two very different possible causes, and each has its own command: **the link itself negotiated wrong**, or **the link is fine and frames are being lost or discarded**. Doing arithmetic on the reported throughput before touching anything narrows it immediately — 90 MB/s is roughly 750 Mb/s, comfortably inside a gigabit link's real-world ceiling and nowhere near 10 Gb. That is the shape of a link that negotiated at 1 Gb, not of a 10 Gb link losing a few percent. ## What the link negotiated ```bash ethtool enp3s0 # Supported link modes: 1000baseT/Full 10000baseT/Full # Auto-negotiation: on # Speed: 1000Mb/s # Duplex: Full # Link detected: yes ``` The fields that matter: - **`Speed:`** — what the link actually came up at. Compare it with `Supported link modes` and with what the hardware is supposed to be. A 10 Gb card reporting 1000Mb/s is the finding. - **`Duplex:`** — should be `Full`. `Half` on modern equipment is nearly always a negotiation failure, and it produces terrible throughput with collisions. - **`Auto-negotiation:`** — `on` is the correct setting on modern Ethernet. Hard-coding speed and duplex on one end while the other auto-negotiates is a classic way to *create* a duplex mismatch. - **`Link detected:`** — `no` means no carrier at all: cable, transceiver, or the switch port is down or disabled. When the speed is wrong, the causes are physical or configuration-level: a cable or patch panel run that cannot carry the higher rate, a transceiver mismatch, a switch port configured for a fixed lower speed, or a forced setting on the host. `ethtool -i enp3s0` tells you the driver, driver version and firmware version, which matters because firmware bugs affecting negotiation are real and the answer is sometimes a firmware update. ## Whether frames are being lost ```bash ip -s link show dev enp3s0 # RX: bytes packets errors dropped ... # ... # TX: bytes packets errors dropped ... ``` The distinction between the two columns is the whole diagnosis: - **errors** — frames that were malformed on arrival or failed transmission. This is a *physical-layer* signal: a damaged cable, a marginal transceiver, electrical noise, or a duplex mismatch. Errors climbing steadily is a hardware ticket. - **dropped** — frames that were intact but the host did not deliver: no buffer space, the queue was full, or the frame was filtered. This is a *host-side* signal: the receive ring or software queue is too small for the burst rate, the CPU handling the interrupts is saturated, or something upstream in the stack is discarding. Absolute values mean little on a host that has been up for a year. What you want is the *rate*: read the counters, wait, read them again, and see how many were added per second relative to total packets. A handful of errors since boot is noise; hundreds a second is your problem. ## Driver-level detail ```bash ethtool -S enp3s0 ``` This dumps the NIC's own statistics. Two things to say honestly about it: the counter names are **driver-specific**, so what you see on an Intel card differs from a Broadcom or Mellanox one, and the useful ones are found by scanning for names containing `err`, `drop`, `miss`, `discard` or `crc`. CRC-type counters point back at the physical layer; missed or no-buffer counters point at the host not keeping up. Related switches that complete the picture: - **`ethtool -g enp3s0`** — the receive and transmit ring sizes, current and maximum. If drops correlate with bursts and the ring is well below its maximum, enlarging it (`ethtool -G`) is a legitimate mitigation. - **`ethtool -k enp3s0`** — offload features. Offloads being off can raise CPU cost substantially at 10 Gb. - **`ethtool -a enp3s0`** — pause-frame (flow control) settings, which matter when a switch is pushing back. ## The limits of looking only at the host The host only ever sees its own end of the link. A duplex or speed problem is a property of both ends, and error counters on the switch port frequently tell a clearer story than the server's do — the switch may be counting CRC errors on frames the NIC never even handed up. Any confident answer here includes "and I'd have the network team read the switch port counters", because that is what turns a suspicion into a confirmed cable or transceiver replacement. Equally, rule out the boring explanations before blaming hardware: the transfer may be limited by disk, by a single-stream protocol that cannot fill a fat pipe, or by something in the path far from this NIC. The value of `ethtool` here is that it settles the *link* question definitively in one command, so you either have your answer or you have eliminated a whole layer.