Slow storage, networking and backup

Why did my 10GbE upgrade not make file copies faster?

Sources checked 2026-10-14 · page updated 2026-10-14 · the question as people ask it: “I put 10GbE cards (and a switch or a DAC) in my NAS and my PC, but file copies are no faster than before - stuck around 100-400 MB/s instead of the ~1 GB/s I expected - so is it the network, the drives, SMB, the slot the card is in, the cable, or my PC, and what do I actually need to buy, if anything?”

Quick answer

A 10GbE link only raises copy speed when every other stage of the copy keeps up with it: the drives behind the share, the SMB session, the client's own port and the PCIe slot each card sits in. Split the problem before buying anything: confirm both ends linked at 10 Gb/s, measure the network alone with iperf3 and the pool alone with fio, then compare the copy with the lower of those two figures. Several of the causes that split finds are configuration (one TCP connection on one core, SMB signing, an MTU mismatch, software bound to the adapter), and hardware is the fix only where the storage, a narrow slot, a slower client port, a failing cable or a refused module is measured as the limit.

What are you seeing?

Pick the closest symptom to open the matching diagnostic path. This is a guide to what to check and in what order; it does not read your system and does not diagnose it.

Confirm both ends trained at 10 Gb/s

1.On each Linux end, NAS and client, print the port's current settings. Find the interface name with 'ip link' and put it in place of enp1s0.
```
sudo ethtool enp1s0
```
ReadingRead the negotiated speed and duplex. 10000Mb/s at full duplex is a 10GbE link. 1000 or 2500 means the link trained low: suspect the cable, the module, the switch port or the far end's own NIC. Check the switch port's speed in the switch's own interface too.
2.On a Windows client, list the adapters and confirm that the 10GbE adapter is the one that is up, and that it is up at 10 Gbps. A motherboard port still cabled to the same network can end up carrying the copy.
```
Get-NetAdapter
```
ReadingA lower speed, or a different adapter carrying the traffic, has to be fixed before any other measurement means anything. In one TrueNAS thread a Windows PC copied at about 90 MB/s until the poster found a stray 1 Gbps cable from a motherboard port to the same switch.
3.Read the error counters before and after a large copy and compare the two readings.
```
sudo ethtool -S enp1s0 | grep -iE 'err|drop|crc|miss'; ip -s -s link show dev enp1s0
```
ReadingError, CRC or drop counters that climb during the copy point at the cable, the module or the port, or at receive overruns. Counters that stay flat clear the physical link. 'ip -s -s link' also prints the interface's mtu and its RX and TX error totals. Counter names differ from driver to driver.

Measure the network alone with iperf3

1.Start an iperf3 server on the NAS. iperf3 moves data from memory, with no disk involved, so what it reports is the network's own ceiling.
```
iperf3 -s
```
2.From the client, run one stream for 30 seconds. Use the NAS's address on the 10GbE subnet, not a hostname that may still resolve to the old 1GbE address.
```
iperf3 -c <nas-ip> -t 30 -O 3
```
Reading-O 3 leaves the first three seconds, TCP slow start, out of the result. This is one TCP connection. Linux receive steering sends the packets of one flow to one queue and CPU, so one flow cannot spread across cores the way several flows can.
3.Run the same test with four parallel streams. From iperf 3.16 onward each stream gets its own thread, so check which version you run.
```
iperf3 -c <nas-ip> -t 30 -O 3 -P 4
```
ReadingSingle stream and -P 4 both near line rate: the network is fine, go to p3 and p4. Single stream short, -P 4 near line rate: the single flow is CPU-limited; iperf3's own documentation says several streams may give more throughput where throughput is CPU-limited, and a single SMB connection hits the same wall unless Multichannel engages (p4). Both short: the link, the slot, the driver or software on one host (p1, p5, p7).
4.Repeat both runs with -R, which makes the NAS send and the client receive, so each direction is measured on its own.
```
iperf3 -c <nas-ip> -t 30 -O 3 -R
```
ReadingIf one direction is much slower, test each machine separately. In one Level1Techs thread, booting the Windows machine from a Linux USB stick gave about 9 and 8 Gbit/s on hardware that was far slower under Windows.
5.On Windows, one ServeTheHome member found -P 4 the minimum needed to reach 10G, and the Windows build of iperf3 runs through Cygwin. Those are forum observations, not iperf3 documentation, so a short single stream from Windows is a reason to try -P 4 before drawing conclusions.

Measure the storage alone with fio and a cache-proof copy

1.On the NAS, run fio against a test file on the pool, never against a block device such as /dev/sdX: a write test aimed at a device destroys the data on it. Replace /mnt/pool with the pool's mount point and size the file larger than the NAS's RAM so the ZFS ARC or the page cache cannot flatter the result. direct=1 asks for non-buffered I/O, usually O_DIRECT; we read no source on how ZFS treats it, which is why the file size matters.
```
fio --name=seqread --filename=/mnt/pool/fio-test --rw=read --bs=1M --size=<larger than RAM> --direct=1 --numjobs=1
```
Readingbw is the pool's sequential read rate with no network in the way. If it is below what iperf3 reported in p2, the pool is the ceiling and a faster network cannot help.
2.Run the write version on the same test file, then remove the file.
```
fio --name=seqwrite --filename=/mnt/pool/fio-test --rw=write --bs=1M --size=<larger than RAM> --direct=1 --numjobs=1
```
ReadingA copy to the NAS can go no faster than this write rate, however fast the link is. Compare it with the iperf3 run in the same direction as the copy.
3.Repeat the slow copy with a file larger than both machines' RAM, twice, and time only the second run. That is Microsoft's own procedure for keeping caches out of a copy test.
ReadingCopy speed close to the lower of the iperf3 and fio figures: the protocol is fine and the slower stage is the ceiling. Copy speed well below both: the cause is in the SMB session or on the client, go to p4 and p5.

Check the SMB session: Multichannel, the Samba side and signing

1.Start a long copy, then query the SMB session from the Windows client while it runs.
```
Get-SmbConnection; Get-SmbMultichannelConnection; Get-SmbClientConfiguration | Select EnableMultichannel; Get-SmbClientNetworkInterface
```
ReadingGet-SmbConnection shows the dialect; Multichannel belongs to SMB 3.0, so a 2.x dialect rules it out. Rows from Get-SmbMultichannelConnection mean Multichannel is in use. No rows mean the session runs on one TCP connection, and Microsoft says that without Multichannel the session sits on a single core where RSS cannot help. Get-SmbClientNetworkInterface shows whether SMB sees the 10GbE NIC and its RSS capability; read the link speed from Get-NetAdapter (p1). Multichannel is on by default since Windows 8 and Server 2012 and needs at least one of: several NICs, an RSS-capable NIC, a NIC team or an RDMA NIC; Windows opens up to 4 connections per RSS interface by default.
2.On a Samba-based NAS, check the server's own setting. Current Samba documentation gives 'server multi channel support = yes' as the default, but NAS firmware may ship an older Samba or override it, so read your NAS's SMB settings rather than assume. smbd runs one copy of the server for each client session, so a single-connection copy is served by one smbd process.
3.Check whether either end requires SMB signing.
```
Get-SmbClientConfiguration | FL RequireSecuritySignature; Get-SmbServerConfiguration | FL RequireSecuritySignature
```
ReadingTrue means this machine requires signing, and for SMB 2.02 and later signing happens if either end requires it. Windows 11 24H2 Pro, Enterprise and Education require it on outbound and inbound SMB; Windows Server 2025 requires it outbound only. Microsoft says signing can increase CPU cost and network round trips, and that Windows Server 2022 and Windows 11 added AES-128-GMAC signing acceleration; we found no Microsoft page giving a size for the slowdown. In one ServeTheHome thread the single slow PC among six was the one with the policy 'Microsoft network client: Digitally sign communications (always)' enabled. Treat it as a security decision: Microsoft's signing page says 'We don't recommend disabling SMB signing as a workaround for third-party servers.'

Check the client: its own port, a USB adapter, software bound to the NIC

1.Confirm the client's own link speed with p1. The slowest link in the path sets the ceiling: in one TrueNAS thread a 10GbE NAS served a PC whose own port was 2.5GbE, and iperf3 first showed about 2.4 Gbit/s. If the client also has a slower adapter on the same network, SMB Multichannel uses the fastest group and leaves the slower adapter idle, so a second port does not add to the copy.
2.A USB Ethernet adapter is bounded by the USB port's own rate. USB-IF names three USB 3.2 rates, 20, 10 and 5 Gbps, and a port running at 5 Gbps cannot carry a 10 Gb/s link at line rate. We found no USB or Thunderbolt Ethernet adapter document stating what such an adapter delivers in practice, so this page gives no figure for one.
3.On Windows, open the 10GbE adapter's properties and read the list of items bound to it. In a Level1Techs thread an Intel 82599 card gave about 5 Gbit/s single-stream under Windows 10 and about 9.3 Gbit/s booted into Ubuntu on the same hardware, after jumbo frames, buffers, RSS and interrupt moderation had changed nothing; the fix was removing the 'Juniper Network Service' and 'ExpressVPN Packet Filter' bindings from the adapter.
4.If one card is slow only under Windows, suspect its Windows driver. A Level1Techs poster's ConnectX-3 ran at about 100 MB/s in a Windows 10 Pro desktop while the same card worked normally in a TrueNAS box, and a used ConnectX-4 Lx on NVIDIA's WinOF-2 driver fixed it. That is one forum report: we hold no NVIDIA statement on that card's Windows support.

Test the MTU end to end, if jumbo frames are set

1.From a Linux machine, send a full-size jumbo packet to the NAS with Don't Fragment set, so an oversize packet fails instead of being split.
```
ping -M do -s 8972 -c 4 <nas-ip>
```
ReadingReplies mean a 9000-byte MTU holds end to end: 8972 is 9000 minus the 20-byte minimum IPv4 header and the 8-byte ICMP header. 'message too long' or no reply, while 'ping -M do -s 1472' gets through, means some hop (client, switch, NAS or a VLAN interface) is still at 1500.
2.If the ping fails, make the MTU the same on every hop, or put every hop back to 1500. On Linux the MTU is set with ip link; Intel's ixgbe driver allows up to 9710.
```
sudo ip link set mtu 9000 dev enp1s0
```
ReadingIn two forum threads, one on TrueNAS and one on Level1Techs, matching the MTU on every hop is what changed the result (the TrueNAS poster, on a 2.5GbE client, reached a steady ~180 MB/s and confirmed no single root cause); we have not read a primary document stating that every hop must share one MTU. Jumbo frames are not a speed fix on their own: in three other threads they gained little or nothing. Intel's ixgbe documentation says an MTU set this way is not saved across reboots. We have not read a TrueNAS or Proxmox document on MTU, so set it in each system's own network settings and re-run the ping.

Check the PCIe slot the NIC sits in

1.Find the NIC's PCI address.
```
lspci -nn | grep -i ethernet
```
ReadingThe first field on the NIC's line is its bus:dev.fn address, used in the next step.
2.Read the link the card supports and the link it got. Run it as root: lspci cannot read parts of config space otherwise.
```
sudo lspci -vv -s <bus:dev.fn> | grep -E 'LnkCap|LnkSta'
```
ReadingLnkCap is what the card supports (speed in GT/s, and width); LnkSta is what the slot negotiated, marked '(downgraded)' when it is below capability. Per lane after line encoding the kernel counts 2 Gb/s at 2.5 GT/s (Gen1), 4 Gb/s at 5 GT/s (Gen2), about 7.88 Gb/s at 8 GT/s (Gen3) and about 15.75 Gb/s at 16 GT/s (Gen4), before packet overhead. Multiply by the LnkSta width: x1 at 5 GT/s is about 4 Gb/s, under one 10 Gb/s port, and a dual-port card needs twice the bandwidth of one port.
3.Check whether the kernel flagged the card when it was enumerated.
```
sudo dmesg | grep -i 'available PCIe bandwidth'
```
ReadingLinux prints '<N> Gb/s available PCIe bandwidth, limited by <speed> x<width> link at <device> (capable of <M> Gb/s with <speed> x<width> link)' only for a device whose available bandwidth is below what it can use, and the line names the limiting link. The line is logged once, when the device is enumerated (normally at boot). Its absence is not proof: LnkSta in the previous step is the check.
4.On Windows, read the same comparison from the adapter's hardware information.
```
Get-NetAdapterHardwareInfo | Format-List Name,PciExpressCurrentLinkWidth,PciExpressMaxLinkWidth,PciExpressCurrentLinkSpeedEncoded,PciExpressMaxLinkSpeedEncoded
```
ReadingCurrentLinkWidth below MaxLinkWidth means the slot gave the card fewer lanes than it can use. The speed fields are codes, and the Microsoft class page we read lists only 1 = 2.5 Gbps and 2 = 5 Gbps, so rely on the width comparison.
5.If the link is narrow, check the board manual for which slots are electrically x4 or x8 and which share lanes with M.2 slots, and move the card. Two ServeTheHome threads show the effect: an 82599 card at x1 Gen2 gave about 3.03 Gbit/s and ran at full speed at x8 Gen2 in the board's one electrically x16 slot, and a ConnectX-3 on a PCIe 2.0 x1 link gave just over 3 Gb/s in iperf. We found no Intel document stating the X520's PCIe generation, so take a card's generation from its own LnkCap, not from its model name.

Check the SFP+ module or DAC the card is using

1.Decode what is actually plugged into the cage.
```
sudo ethtool -m enp1s0
```
ReadingShows the module or DAC's type, vendor and part number and, for optics, the wavelength. An error, or nothing decoded, can mean a module the driver does not read.
2.On Intel 82599-based cards, Linux's ixgbe driver accepts passive and active limiting DACs that comply with SFF-8431 v4.1; 82598-based cards do not take active DACs. On 82599-based cards the driver has an allow_unsupported_sfp parameter, off by default, that allows unsupported and untested SFP+ modules as long as the driver knows the module type. Other NICs and switches have their own module policies, so check the card's and the switch's own documents.
3.Match optics to each other and to the fibre: SR faces SR over multimode, LR faces LR over single-mode. Cisco's figures for its own parts are SR 300 m on OM3 and 400 m on OM4, LR 10 km on single-mode, passive twinax 1-5 m and active twinax 7 and 10 m; other makers' reaches differ. In one Level1Techs thread, swapping fibre, optical and copper modules on a link that was up changed nothing.

Causes, how to confirm each, and whether hardware fixes it

Cause	How to confirm	Fix	Hardware?
The storage is slower than the network	fio on a test file on the pool (p3) reports less bandwidth than iperf3 (p2), and the cache-proof copy runs near the fio figure	Storage that measures faster in fio than the iperf3 figure; a faster network cannot lift this ceiling, so a NIC is the wrong purchase here. In two forum threads replies blamed the drives or the pool layout rather than the network, which is opinion, not a measurement. Drives are listed on /nas-hdd and /nvme-u2.	Yes
The copy runs on one TCP connection, processed by one CPU core	iperf3 single stream stops short of line rate while -P 4 reaches it, and Get-SmbMultichannelConnection returns no rows during a copy	Get SMB Multichannel to engage: an SMB 3.x dialect, a NIC Windows reports as RSS-capable, and multichannel support enabled on the NAS's Samba. Check each before changing hardware.	No
One end requires SMB signing	RequireSecuritySignature reads True on the client or the server; Windows 11 24H2 Pro, Enterprise and Education require it by default	A security decision, not a tuning step: Microsoft advises against disabling signing as a workaround for third-party servers. Knowing it is on explains a CPU-bound copy.	No
Software or a driver in the client's network stack	iperf3 is short under Windows but near line rate when the same machine boots Linux, or a VPN or packet-filter item is bound to the adapter in its properties	Unbind or remove the extra items from the 10GbE adapter, as in the thread where two VPN filter bindings were the whole cause; if only one card's Windows driver is slow, test another driver or card.	No
Traffic still takes the old 1GbE path	iperf3 to the NAS's 10GbE address is fast while copies to its hostname are slow, or Get-NetAdapter shows a slower adapter on the same network carrying the traffic	Address the NAS by its 10GbE IP or correct name resolution, and unplug or reconfigure the stray port.	No
MTU mismatch somewhere on the path	On a path where at least one end is set to 9000, ping -M do -s 8972 fails while ping -M do -s 1472 succeeds	Match the MTU on every hop, which is what changed the result in two forum threads, or put every hop back to 1500; we have not read a primary document stating that every hop must share one MTU.	No
The client's own port is slower than 10GbE: a 2.5GbE onboard port, or a USB adapter on a 5 Gbps port	ethtool or Get-NetAdapter shows 2500Mb/s on the client, or the client's 10GbE adapter is on a USB port running at 5 Gbps; for an adapter on a faster USB port this page has no sourced figure	A 10GbE NIC in a PCIe slot of the client, after checking that slot with p7.	Yes
The NIC sits in a slot wired narrower or slower than it needs	LnkSta '(downgraded)' or CurrentLinkWidth below MaxLinkWidth, or the boot line naming the limiting link; LnkSta width times the per-lane rate comes out below 10 Gb/s per port	Move the card to a slot wired wider, using the board manual and its M.2 lane-sharing notes. If no such slot is free, a card whose own PCIe generation and width suit the slot you have.	Yes
The link trains below 10 Gb/s, or errors climb during the copy	ethtool shows 1000 or 2500Mb/s on a 10GbE port, or ethtool -S error, CRC or drop counters rise during a copy	Swap the cable, the module and the switch port one at a time; replace whichever part's swap clears it with a matched DAC or module.	Yes
A refused or mismatched SFP+ module or DAC	ethtool -m decodes nothing or the wrong type, or the two ends carry different optics (SR against LR) or sit on the wrong fibre	A DAC or module the card accepts, matched at both ends. On 82599-based cards the ixgbe driver's allow_unsupported_sfp parameter, off by default, allows unsupported and untested SFP+ modules as long as the driver knows the module type.	Yes

If the client or the slot needs a different 10GbE card

Three diagnoses on this page end in a new network card: a client held back by its own 2.5GbE port, a client on a USB adapter whose port runs at 5 Gbps, or a NIC in a narrow slot with no wider slot free. The list below is 10GbE NICs with an SFP+ or RJ45 connector; our catalogue stores no PCIe generation or lane width, no driver support and no RSS capability for them, so read your slot with lspci or Get-NetAdapterHardwareInfo, check each card's own documents for generation, width and drivers, and and match the connector to the port at the other end, or plan the DAC or module that joins them, before you buy.

When not to buy: Do not buy a card if iperf3 already reaches near line rate in both directions (the network is fine), or if fio on the pool reads below the iperf3 figure (the storage is the ceiling, and drives fix that, not a NIC). A refused module or a failing cable calls for a matched DAC or transceiver from the pages linked below, and signing, Multichannel, MTU and software bound to the adapter are fixed in configuration.

Every row below meets: Stored link speed is 10G (a NIC that can carry a 10GbE link) · Connector family stored as SFP+ or RJ45, so it can be matched to the port on the other end. A listing whose field is not stated is excluded from a required criterion and marked “not stated” on an optional one; nothing is assumed. What the catalogue cannot evaluate: NIC PCIe generation and lane width (does it fit an x1/x4 slot); Windows/driver support, RSS or RDMA capability, chipset; Switch port type and which ports are 10G (needed to match the NIC/DAC to the other end); DAC length and active vs passive; Vendor coding / module acceptance by the NIC (e.g. ixgbe allow_unsupported_sfp). Check these on the maker's data sheet.

Product · part number	Cap.	Interface · form · rating	Condition	Price	$/TB	Buy
Mellanox ConnectX-3 1-port SFP+ — · details	—	SFP+ · PCIe	NEW Amazon: New / Unknown · sold by StallionTek Certified	$27.99	—	Buy on Amazon
10Gtek RJ45 card (Intel X540 claimed) — · details	—	RJ45 · PCIe	REFURB / USED Amazon: Used / LikeNew · sold by 10Gtek · seller's note on the listing	$38.39	—	Buy on Amazon
Intel X520 2-port SFP+ — · details	—	SFP+ · PCIe	REFURB / USED Amazon: Used / LikeNew · sold by MaraviCanada · seller's note on the listing	$39.99	—	Buy on Amazon
H!Fiber RJ45 card (Intel X540 claimed) — · details	—	RJ45 · PCIe	REFURB / USED Amazon: Used / LikeNew · sold by Ipolex HK · seller's note on the listing	$40.49	—	Buy on Amazon
ipolex RJ45 card (Intel X540 claimed) — · details	—	RJ45 · PCIe	REFURB / USED Amazon: Used / LikeNew · sold by ipolex · seller's note on the listing	$41.39	—	Buy on Amazon
Intel X520 2-port SFP+ — · details	—	SFP+ · PCIe	REFURB / USED Amazon: Used / Good · sold by TECH XP	$45.00	—	Buy on Amazon
Intel X520 2-port SFP+ — · details	—	SFP+ · PCIe	REFURB / USED Amazon: Used / Good · sold by TECH XP	$49.99	—	Buy on Amazon
10Gtek SFP+ card (Intel X520 claimed) — · details	—	SFP+ · PCIe	NEW Amazon: New / Unknown · sold by 10Gtek	$49.99	—	Buy on Amazon
10Gtek SFP+ card (Intel X520 claimed) — · details	—	SFP+ · PCIe	NEW Amazon: New / Unknown · sold by 10Gtek	$57.99	—	Buy on Amazon
10Gtek SFP+ card (Intel X710 claimed) — · details	—	SFP+ · PCIe	REFURB / USED Amazon: Used / LikeNew · sold by 10Gtek · seller's note on the listing	$87.99	—	Buy on Amazon
Intel X540 2-port RJ45 — · details	—	RJ45 · PCIe	REFURB / USED Amazon: Used / VeryGood · sold by GENUINE-HARDWARE	$89.00	—	Buy on Amazon
Intel X710 2-port SFP+ — · details	—	SFP+ · PCIe	REFURB / USED Amazon: Used / LikeNew · sold by HaehnleinIT Inc. · seller's note on the listing	$89.90	—	Buy on Amazon

Prices are Amazon US, re-checked about once a day; newest price in this table 2026-10-14 22:19 UTC. A click here is a click, not a purchase; we earn a commission on qualifying purchases. The table shows what the catalogue holds against the criteria, not an endorsement of any model for your server.

Frequently asked questions

Will bonding two 10GbE ports make one copy faster?

Not by the Linux bonding documentation we read: with layer3+4 hashing, traffic to one peer can spread across links but a single connection never spans more than one, and with layer2 hashing all traffic to one peer uses one link. A single-connection SMB copy therefore stays on one port. We read only those two hash policies, so this says nothing about other bonding modes.

Should I raise TCP buffers or change flow control and interrupt moderation?

Linux already auto-tunes TCP socket buffers up to the tcp_rmem and tcp_wmem maximums, and Intel's ixgbe driver turns Ethernet flow control on by default. No source we read says changing either fixes a LAN 10GbE copy, and in the forum threads buffer tunables, flow control and interrupt moderation changes made no measurable difference. Measure with iperf3 and fio first.

Will my existing Cat6 cable carry 10GBASE-T?

We have not read the ratified IEEE 802.3an clause or the TIA and ISO cabling standards, which are paywalled, so this page gives no sourced reach per cable category. The 10GBASE-T study group's 2003 objectives set at least 100 m on ISO Class F cabling and at least 55 m to 100 m on Class E; those are objectives in ISO class terms, not Category names. An SFP+ RJ45 module can be rated far shorter than a NIC port: Cisco rates its SFP-10G-T-X at up to 30 m on Cat6A/Cat7 or better, drawing 2.5 W. ethtool shows whether your link trained at 10000Mb/s, and its counters whether the link is clean.

Would NFS be faster than SMB for this copy?

We have not read an NFS server or client document, so this page does not compare the two. Forum replies suggested trying NFS as a comparison without a reported outcome. The same split applies to either protocol: if iperf3 and fio are both fast and the copy is not, the protocol or the client is the stage to examine.

Sources

Every technical statement above rests on one of these documents, each read on the date shown. Where a document did not state something, the page says so rather than filling the gap.

ethtool(8) man page (ethtool 7.1) · checked 2026-10-14
iperf3 - Invoking iperf3 · checked 2026-10-14
Linux kernel Documentation/networking/scaling (RSS, RPS, RFS, XPS) · checked 2026-10-14
Linux kernel Documentation/networking/bonding - xmit_hash_policy layer3+4 · checked 2026-10-14
Linux kernel ixgbe driver documentation (Intel 82598/82599/X540/X550) · checked 2026-10-14
ip-link(8) and ip(8) man pages · checked 2026-10-14
ping(8) man page (iputils 20250605) · checked 2026-10-14
RFC 791 - Internet Protocol (IHL field) · checked 2026-10-14
Linux kernel drivers/pci/pci.h - PCIE_SPEED2MBS_ENC · checked 2026-10-14
Linux kernel drivers/pci/pci.c - __pcie_print_link_status(); drivers/pci/probe.c - pcie_report_downtraining() · checked 2026-10-14
pciutils ls-caps.c cap_express_link() and link_compare(); lspci(8) man page · checked 2026-10-14
Manage SMB Multichannel (Microsoft Learn) · checked 2026-10-14
Deploy SMB Multichannel (Windows Server 2012/2012 R2, archived) · checked 2026-10-14
Performance tuning for file servers (Microsoft Learn) · checked 2026-10-14
Control SMB signing behavior (Microsoft Learn) · checked 2026-10-14
Overview of Server Message Block signing (Microsoft Learn) · checked 2026-10-14
Get-NetAdapterHardwareInfo cmdlet; MSFT_NetAdapterHardwareInfoSettingData class · checked 2026-10-14
Samba smb.conf(5) - server multi channel support, server signing · checked 2026-10-14
Samba smbd(8) man page · checked 2026-10-14
IEEE 802.3 10GBASE-T Study Group Objectives (Portonovo, September 2003) · checked 2026-10-14
Cisco 10GBASE SFP+ Modules Data Sheet · checked 2026-10-14
USB-IF: USB 3.2 · checked 2026-10-14
fio HOWTO (fio_doc) · checked 2026-10-14
Linux kernel Documentation/networking/ip-sysctl - tcp_rmem / tcp_wmem · checked 2026-10-14

Where people hit this

Discussions we opened and read while researching this page. They are evidence that the problem occurs and of what people tried; no specification above is sourced to a forum post.

Level1Techs · 2020-05-01 · Two FreeNAS boxes on 10GbE SFP+ copied at under 100 MB/s and about 180 MB/s while NVMe clients copied to each other at 300-450 MB/s. Replies asked for a local copy on the NAS and iperf3 to separate storage from network, large files, an SMB against NFS comparison and an MTU 9000 test, which gained little. No iperf3 result or confirmed fix on page 1.
“I just can NOT figure out how to make FreeNAS generate much throughput.”
Level1Techs · 2018-05-17 · FreeNAS on six drives in one RAIDZ2 vdev with an Intel X540-T1, to a Windows 10 workstation: SMB copies started at 300-350 MB/s and decayed to 130-150 MB/s. Buffer tunables, interrupt moderation and a jumbo-frame test did not help; replies said to benchmark disks and network separately and check PCIe lane contention, and a later reply blamed the drives. No confirmed fix.
Level1Techs · 2024-09-04 · TrueNAS SCALE with eight 12TB drives in two four-drive RAIDZ1 vdevs, to a desktop whose 10GbE card sat on a PCIe Gen4 x1 adapter: Explorer copies topped out at 360 MB/s. Replies asked for iperf3 both ways with one and several streams and a local pool benchmark, and one estimated the RAIDZ1 layout's own limit near the observed figure. No confirmed cause.
“I'm only getting a maximum throughput of 360MB/s, according to File Explorer.”
ServeTheHome forums · 2021-01-20 · A Windows 10 client to a Synology DS918+ over SR optics on OM4: single-stream iperf3 from Windows averaged about 403 Mbit/s and SMB copies 70-120 MB/s. Replies said Windows needs parallel iperf3 streams, that the Windows build runs through Cygwin, and that iperf3 in an Ubuntu VM did much better. No root cause on page 1.
“I found with windows, iper3 -P4 is the minimum number of threads to get the full 10G.”
ServeTheHome forums · 2024-12-11 · One Windows 11 PC copied to two Synology units far slower than five other PCs on the same switch. Drivers, cables, ports, jumbo frames, flow control, TCP autotuning, BIOS and slot swaps changed nothing; the cause was the client policy 'Microsoft network client: Digitally sign communications (always)' being enabled.
“Windows was signing the packets and massively slowing down the transfer speeds.”
ServeTheHome forums · 2025-02-27 · An Intel 82599ES card negotiated x1 Gen2 in a B650 board's secondary slots and gave about 3.03 Gbit/s; in the one electrically x16 slot it ran x8 Gen2 at full speed. No BIOS setting helped; replies suggested an M.2-to-10GbE adapter in a CPU-attached M.2 slot or a newer card.
“Only one slot is electrically x16, others seems to be x1 lane.”
ServeTheHome forums · 2021-08-03 · A TrueNAS builder with only a PCIe 2.0 x1 link in an x16-sized slot asked about a 10GbE card; a member running a ConnectX-3 that way on an X470 board measured just over 3 Gbit/s in iperf, and the poster accepted the x1 ceiling.
“I'm able to get just over 3Gb/sec on an iperf run.”
Level1Techs · 2020-09-03 · Intel SFP+ cards between Windows 10 and Debian 10: Samba about 980 one way and about 400 the other, iperf asymmetric after a reboot. Swapping fibre, optical and copper modules changed nothing; booting the Windows box from a Linux USB stick gave about 9 and 8 Gbit/s. Intel's Windows tuning raised Samba to about 700; closed without a fix.
“So Its apparently something with windows?”
Level1Techs · 2026-01-24 · An 82599 card in an x16-sized slot wired x4 gave about 5 Gbit/s single-stream and 6 parallel under Windows 10 and about 9.3 Gbit/s in Ubuntu on the same hardware; two other cards did no better, and jumbo frames, buffers, RSS, interrupt moderation, C-states and LSO changed nothing. The fix was removing the Juniper and ExpressVPN filter bindings from the adapter.
“I was able to disable and/or uninstall both of them via the properties panel of my Intel 82599 NIC.”
Level1Techs · 2024-11-12 · A ConnectX-3 in a Windows 10 Pro desktop ran at about 100 MB/s while the same card worked normally in a TrueNAS box. Driver and BIOS updates, lane changes and Windows settings did not help; a used ConnectX-4 Lx on NVIDIA's WinOF-2 driver gave 10GbE speeds.
“It just works like it's supposed to 10GBE speed.”
TrueNAS Community forums · 2025-09-10 · TrueNAS SCALE with a 10GbE card on a mostly 10GbE network, but the client PC's own link was 2.5GbE; iperf3 first showed about 2.4 Gbit/s and writes sat near 120 MB/s. After many settings changes, matching MTU 9014 on the NAS, the router and the PC gave a steady ~180 MB/s; no single root cause was confirmed.
“I was able to make the speed an extremely consistent 180 megabytes per second.”
TrueNAS Community forums · 2025-06-11 · An all-NVMe TrueNAS SCALE box served Macs at about 900 MB/s and a Windows 10 PC with a 10GbE card at about 90 MB/s. No iperf3 was run; the poster found a stray 1 Gbps cable from a motherboard port to the same switch, and moving it restored Windows speeds. The poster's Multichannel explanation was disputed in-thread and never confirmed.
Level1Techs · 2025-03-13 · A TrueNAS SCALE box directly connected to a Windows 10 client whose own NIC was 1GbE: iperf3 about 950 Mbit/s both ways but SMB writes about 680 Mbit/s. Signing, Multichannel, autotuning, RSS, buffers and LSO changes did not help; setting jumbo packet 9014 on Windows and the exact matching MTU on TrueNAS did. Relevant for the MTU fix and the client-port ceiling, not for 10GbE throughput.
“After this was changed - transfer speed shot up to max”

Other slow storage, networking and backup problems

Share:WhatsApp Facebook Post on X