A device's Ethernet link is up but throughput is terrible under load. What might be wrong?

A leading suspect is a duplex mismatch from auto-negotiation gone wrong. Each end's PHY negotiates speed and duplex with its link partner; if one end is hard-configured to full-duplex while the other falls back to half-duplex (which happens when one side is forced and the other auto-negotiates), the half-duplex side runs CSMA/CD and sees the full-duplex side's simultaneous transmissions as collisions, producing late collisions, CRC/FCS errors, and retransmissions that crater throughput specifically under load while a light ping still works, a very characteristic symptom. The fix is to make both ends agree: let both auto-negotiate, or force both to the same speed and duplex. Other under-load culprits: a marginal physical layer (bad cable, magnetics, or signal integrity) showing up as FCS errors that escalate with traffic; an undersized or mismanaged buffer/descriptor ring in the MAC driver causing drops when packets burst; MTU/fragmentation issues where large transfers stall; or simply the small MCU stack's limited TCP window and buffer count throttling sustained throughput. The diagnostic approach is to read the PHY/MAC error counters (FCS errors, collisions) and the negotiated speed/duplex, and check whether errors correlate with load. "Link up but slow under load" almost always points to duplex mismatch or physical-layer errors rather than application code.