Move work from the processor to the card - and at high speeds that decides whether the server does its job or spends its time on networking.

Checksum offload has the card calculate and verify packet checksums instead of the processor. Segmentation offload lets the operating system hand down a large block which the card divides into packets, greatly reducing the number of operations. Receive-side scaling distributes incoming traffic across multiple processor cores instead of overloading one - which is often the single most significant setting.

At gigabit speeds none of this matters much. At 10 Gb and above it matters a great deal: without offloads, saturating the link can consume much of a processor.

More advanced techniques bypass the operating system stack entirely for applications that need minimal latency.

The practical point is that offloads must be supported by the card, enabled by the driver and not disabled by configuration - and they are sometimes turned off during troubleshooting and never turned back on.

Enough to carry its rated throughput at the slot's generation - and the electrical width is often less than the physical connector suggests.

Each PCIe lane carries a defined bandwidth that doubles with each generation. A card needs total lane bandwidth exceeding its aggregate port speed, with margin for overheads.

A dual-port 25 Gb card needs 50 Gb of host bandwidth, which requires a meaningful number of lanes at older generations and fewer at newer ones. Installed in an insufficient slot it will work and simply not reach its rated speed - a fault that looks like a network problem and is not.

The trap is that a physically long slot may be electrically narrower. Server documentation states the electrical width per slot, and it varies between slots on the same board.

Check the slot before choosing the card, particularly in older servers being upgraded with newer network cards - which is the most common place this goes wrong.

Two separate cards give better redundancy; one dual-port card is cheaper and uses one slot. Which matters depends on what the redundancy is for.

A dual-port card protects against a cable, transceiver or switch failure, since the two ports can go to two switches. It does not protect against the card itself failing, or against the slot or its driver.

Two single-port cards in different slots remove that shared dependency entirely, at the cost of a second slot and a higher price.

For most workloads a dual-port card teamed across two switches is the right balance - card failures are much rarer than cable, optic and switch failures.

For systems where availability is the primary requirement, two cards is the correct answer, and they should ideally be from different slots on different buses.

Either way, confirm the teaming or bonding configuration matches what the switches expect, and test failover by pulling a cable rather than assuming.

SR-IOV and the associated offloads, where virtual machines need network performance close to bare metal.

By default a hypervisor presents virtual network adaptors to its guests and switches traffic in software, which costs processor time and adds latency. For most workloads that is entirely acceptable.

SR-IOV lets the physical card present multiple virtual functions directly to guests, so a virtual machine talks to the hardware without the hypervisor in the path. Throughput and latency improve substantially and processor overhead falls.

The trade is flexibility: guests using it are tied more closely to the hardware, and features such as live migration and some virtual switching can be restricted or unavailable.

Offloads for overlay encapsulation matter too - if the environment uses VXLAN or similar, a card that handles the encapsulation in hardware avoids a significant processor penalty.

Confirm the hypervisor supports the specific card, since compatibility lists are narrower than the marketing suggests.

Copper for gigabit and short 10 Gb runs; pluggable transceivers for anything faster or longer - and in a data centre, direct attach cables for in-rack connections.

Copper is simple and cheap at gigabit. At 10 Gb over twisted pair it works but consumes noticeably more power per port and generates more heat at both ends, which matters across a rack of servers.

Above 10 Gb, cards use cages for pluggable transceivers, which lets the same card serve fibre, copper twinax or active optical cables depending on what is fitted.

For server-to-top-of-rack connections within a rack, direct attach copper cables are the standard choice: cheapest, lowest power, lowest latency, and no optics to fail or clean.

Between racks or rows, optical transceivers with fibre are used.

Check transceiver compatibility. Some cards accept only vendor-coded modules, or need a configuration setting to accept third-party ones, and this regularly produces a link that will not come up.

Frequently more - driver quality and firmware currency determine stability and performance more than the silicon does.

A card's offload features exist only if the driver implements them. The same hardware can perform very differently on different operating systems or driver versions, and default settings vary.

Firmware and driver must usually be kept in step. A mismatched pair is a recognised cause of intermittent faults - packet loss under load, unexplained resets, or offloads that silently stop working - and it is rarely the first thing anyone checks.

For servers, use the driver and firmware combination the server manufacturer qualifies rather than the newest available, and update them together during maintenance.

Check support for the operating system in use before buying, including any specialist or older systems. Support for current mainstream systems is universal; support for a particular virtualisation platform, a real-time system or an older release is not.

Negotiated speed, slot width, offload settings, driver and firmware versions, and errors at both ends - in that order, because the first two explain most cases.

Check the negotiated link speed and duplex. A link that has fallen back to a lower speed because of a cable or transceiver problem is the commonest cause and the easiest to confirm.

Check the slot's electrical width against the card's requirement. An undersized slot caps throughput with no error anywhere.

Check the offloads are enabled. They are often disabled during troubleshooting or by a configuration template and never restored.

Compare driver and firmware versions against the manufacturer's recommended pairing.

Look at error counters on the card and on the switch port. Rising errors point to cabling or a transceiver; clean counters with low throughput point at the host.

And test with a tool that can saturate the link, since application-level slowness often has nothing to do with the card at all.