Start an order
Technical guide • Windows

Make the connection
work for Windows.

A practical guide to measuring and tuning Windows systems for 10 Gbps, 25 Gbps, 100 Gbps, and faster connections.

Prepared by Stealth CommunicationsNovember 1, 2026Approx. 10 min read

The short version

Where should you start?

At 10 Gbps and above, the Windows device, its adapter and PCIe connection, the local network, the Internet path, and the destination all matter. Begin with a repeatable test and interface evidence before changing operating-system settings.

There is no universal tuning profile

Windows features, adapter drivers, policy, workloads, and hardware differ. A setting that helps one server may not help a laptop, and some changes can interrupt a working connection.

This guide describes common Windows workstation and server concepts. Microsoft’s detailed performance guidance is written for Windows Server; confirm applicability to your installed Windows version, adapter driver, and organization’s policy. Discuss these examples with your company’s IT team before making changes. The inspection commands are read-only; viewing some properties may require authorized administrator access.

01 / Establish the baseline

Measure the work you care about.

Record the Windows version, adapter model and driver, negotiated link speed, test destination, traffic direction, and time. Use a suitable wired connection for a wired performance test and verify that a VPN or another interface is not taking the traffic along a different path.

Repeat tests under comparable conditions, in both directions, with permission from the operator of the destination. Record the receiver’s throughput, latency, errors, CPU usage, and competing workload. Some endpoints and public servers are shared or rate-limited, and the network path and destination can change.

For a controlled example, run the following from a separate Windows host with iperf3 installed and permission to use the server. After the version check, the first two tests compare one TCP connection with eight; the third tests the reverse direction:

iperf3 --version
iperf3 -c iperf3.stealth.net -P 1 -t 10
iperf3 -c iperf3.stealth.net -P 8 -t 10
iperf3 -c iperf3.stealth.net -P 8 -t 10 -R
Plan the test. These are full-rate tests and can disturb other traffic. A ten-second test at 100 Gbps can transfer approximately 125 GB in one direction. Schedule accordingly. A result reflects the test software, host, peer, and path; a shared public server may not sustain your target rate. Follow applicable software and test-service terms.

See the speed-test guide for test preparation and interpretation.

iperf3 --version checks the installed test tool. Version 3.16 and later use a separate thread for each test stream; earlier versions can be limited by one CPU core even with -P 8. Check the version on the other endpoint too when you manage it. On Windows, confirm that your organization supports the chosen iperf3 build. Threading helps the test use available cores; it does not make one TCP stream use eight cores or guarantee a higher result.

02 / The physical path

Check the adapter and its negotiated speed.

In PowerShell, list adapters and identify the one carrying the test. The following read-only command displays each adapter’s status and link speed:

Get-NetAdapter | Format-Table Name, InterfaceDescription, Status, LinkSpeed

A 10 Gbps service cannot make a 1 Gbps adapter transfer at 10 Gbps. Check the adapter, driver, cabling or optics, dock, connected switch port, and firewall. For 25 Gbps or 100 Gbps systems, check that the server’s PCIe slot and lanes can carry the adapter’s intended load, and review the adapter vendor’s NUMA and CPU-placement recommendations. The port speed is a link property, not a promise of end-to-end application throughput. Adapters can report speeds differently; verify against the hardware and switch. To inspect the named adapter and its driver, replace Ethernet with the name from the list:

Get-NetAdapter -Name "Ethernet" | Format-List Name, InterfaceDescription, DriverVersion, DriverDate, LinkSpeed

For a wireless issue, assess signal, channel use, access-point capacity, and client capability separately. Compare with a capable wired device where practical. Our Ethernet vs. Wi-Fi guide explains the difference.

03 / Link health

Look for errors that increase during a test.

Replace Ethernet with the adapter name shown by Get-NetAdapter. Capture two read-only counter snapshots over a known interval:

Get-NetAdapterStatistics -Name "Ethernet" | Format-List *

Review available errors and discards on the Windows adapter, switch, and other relevant interfaces through the provider handoff. Counter definitions and availability depend on the driver. An old total alone does not show an active problem; do not clear counters before preserving the evidence. Screenshots and output can contain network identifiers; review them before sharing.

Use Task Manager or Performance Monitor to examine CPU, memory and disk activity during the same test. A busy application, endpoint storage, encryption, or software inspection can constrain throughput even when the link reports a high rate.

04 / TCP & buffers

Give a long path room for data.

TCP can have data in flight while acknowledgments return. The bandwidth-delay product is an estimate of the data needed to fill a path: rate in bits per second × round-trip seconds ÷ 8.

Illustration: At 40 ms round-trip time, 10 Gbps corresponds to about 50 MB in flight. The same path at 25 Gbps corresponds to 125 MB, and at 100 Gbps, 500 MB. These are decimal megabytes and theoretical path estimates, not buffer values to copy into Windows.

TCP receive-window autotuning can expand the receive window as appropriate. Congestion control, sender and receiver behavior, loss, application settings, and memory limits also matter. A single connection needs sufficient in-flight data to use the path; multiple streams can share that requirement and produce a different aggregate result. The estimate is not a direct prescription for an application’s socket buffer. A large buffer limit is not the same as memory preallocated to each connection.

These read-only commands display the current global TCP view and available TCP profiles. Some output or management operations can require an authorized elevated PowerShell session:

netsh interface tcp show global
Get-NetTCPSetting | Select-Object SettingName, AutoTuningLevelLocal, AutoTuningLevelGroupPolicy

Microsoft identifies Normal as the default receive-window autotuning level in its Windows Server guidance. Record what your system and policies actually use. If it was deliberately restricted by policy, contact the administrator before changing it; do not assume every profile or connection uses the same configuration.

A test-only socket-buffer experiment. With your IT team and an authorized test peer, you can compare the earlier single-stream baseline with an explicit 32 MiB request:

iperf3 -c iperf3.stealth.net -P 1 -t 10 -w 32M
iperf3 -c iperf3.stealth.net -P 1 -t 10 -R -w 32M

This asks iperf3 to set socket buffers on both endpoints for that test. It may change automatic sizing behavior and can fail if the peer’s limits or permissions do not allow the request. The actual allocation or effective window may differ by operating system; it is not a system-wide Windows setting. After comparing with the same tests without -w, omit -w on future runs to return to the test’s defaults. Do not assume the shared public endpoint can support the desired rate or requested size.

When an approved correction is appropriate: If your administrator has confirmed that a global autotuning setting was unintentionally disabled and that normal is appropriate, an elevated command prompt can apply netsh interface tcp set global autotuninglevel=normal. First record the exact previous state and any group policy, test the application, and use the documented netsh command with the recorded previous level to roll back. The command changes a host-wide setting and may not override policy. Run netsh interface tcp show global again to verify the result, then repeat the same tests with new connections. If needed, restore the recorded prior level with netsh interface tcp set global autotuninglevel=<prior-level>, replacing the placeholder with the original value. Do not apply it as a blanket speed fix.

05 / Adapter processing

What do queues and offloads do?

Receive-side scaling, or RSS, can distribute processing for eligible receive traffic across CPUs. Adapter checksum and segmentation offloads can reduce processing work on the host. Benefits depend on the adapter, driver, traffic, and CPU; features and names differ by product.

Inspect the named adapter’s reported RSS and advanced properties if supported. These commands display settings and do not modify them:

Get-NetAdapterRss -Name "Ethernet" | Format-List *
Get-NetAdapterChecksumOffload -Name "Ethernet"
Get-NetAdapterLso -Name "Ethernet"
Get-NetAdapterAdvancedProperty -Name "Ethernet"

Some drivers do not expose these features or require elevated access. Do not disable RSS, checksum or segmentation offloads across the board. If measurements point to an adapter or driver issue, consult the vendor and test a supported change in a maintenance window. Microsoft notes that some older offload technologies are deprecated on Windows Server; do not assume an old tuning recipe applies to a current release.

A single TCP flow is normally handled on one RSS processor at a time, so compare single-flow and multiple-flow results and inspect individual logical CPUs; a low system-wide CPU average can hide one saturated core. On virtualized servers, also inspect the hypervisor and virtual network path. Interrupt moderation can reduce CPU overhead by batching work but may affect latency. Queue counts and CPU placement are workload- and hardware-specific. Change them only when evidence and the driver documentation support an experiment.

Example: a supported adapter with RSS unintentionally disabled. If the adapter, driver and workload support RSS, and the administrator confirms it is appropriate, record Get-NetAdapterRss -Name "Ethernet" | Format-List * before a maintenance window. In an elevated PowerShell session, Enable-NetAdapterRss -Name "Ethernet" enables it and can restart the adapter, interrupting access. Confirm its status with the same inspection command and repeat the test. If the original state was disabled and a rollback is needed, Disable-NetAdapterRss -Name "Ethernet" restores that state and can also restart the adapter. Check policy and the vendor’s instructions first, and retain local or out-of-band access.

For 100 Gbps and above, investigate per-core CPU use, adapter queues, packet size, PCIe capacity, NUMA placement, offloads, and the test peer before attributing a limit to TCP buffers.

A practical adapter example

Try a larger receive buffer on a supported adapter.

Some Windows network adapters expose a receive-buffer setting in their driver. These are adapter resources, separate from the TCP receive window. A larger setting can help when measurement and the adapter vendor identify a receive-resource bottleneck; it will not fix every throughput problem.

For this example only, suppose your IT team finds that the adapter named Ethernet exposes a property named Receive Buffers, its current value is 1024, and its driver explicitly supports 2048. The name, values and units vary by driver; those numbers are not recommendations for every adapter. In an elevated PowerShell session, inspect and record the original value and the driver’s available values:

Get-NetAdapterAdvancedProperty -Name "Ethernet" -DisplayName "Receive Buffers" |
  Format-List DisplayName, DisplayValue, ValidDisplayValues

If the property or valid values are unavailable, or your IT team cannot confirm support, stop and check the vendor documentation. After approval and a maintenance window, the following example changes that exact property to 2048. It may restart the adapter and interrupt connectivity, so retain local or out-of-band access:

Set-NetAdapterAdvancedProperty -Name "Ethernet" -DisplayName "Receive Buffers" -DisplayValue "2048"
Get-NetAdapterAdvancedProperty -Name "Ethernet" -DisplayName "Receive Buffers" |
  Format-List DisplayName, DisplayValue, ValidDisplayValues

Repeat the receiving test and review adapter drops, CPU, memory and application behavior. If the recorded original really was 1024 and the current value remains 2048, the following restores this example’s original setting; verify it afterward. If either value differs, stop and work with IT rather than applying this rollback blindly.

Set-NetAdapterAdvancedProperty -Name "Ethernet" -DisplayName "Receive Buffers" -DisplayValue "1024"
Get-NetAdapterAdvancedProperty -Name "Ethernet" -DisplayName "Receive Buffers" |
  Format-List DisplayName, DisplayValue

Restoration may also restart the adapter. Change only one property at a time and keep the original value in the change record.

06 / MTU & link configuration

Match both ends and the path.

Speed, duplex, and MTU settings must be appropriate for the adapter and its peer. Automatic negotiation is usually the starting point; do not force a speed or disable negotiation without the network team and equipment documentation. Record current settings and check both ends when investigating a mismatch.

Jumbo frames may help a designed local workload by reducing per-packet overhead, but they are not a universal Internet speed switch. Validate support and path-MTU behavior across the intended path first; mismatches can disrupt applications. A change to adapter properties can interrupt connectivity.

07 / Change control

Test one change at a time.

  1. 01

    Record the starting state

    Capture the current setting, applicable policies, link status, test results, and adapter version. Confirm local or out-of-band access in case the network is interrupted.

  2. 02

    Choose a supported change

    Use Microsoft and adapter-vendor guidance for the Windows version and observed bottleneck. Get authorization, choose a maintenance window, and define how to restore the recorded values. A driver or adapter change may reset a link or require a restart.

  3. 03

    Repeat and compare

    Use the same test, endpoints, directions, and workload. Check application behavior, latency, errors, and CPU as well as throughput. Roll back if the result worsens or the change is not useful.

Large file transfers

Test the transfer your team actually uses.

With your IT team, select a representative, non-sensitive large file and an approved destination. Time a complete transfer using the application and security settings your business normally uses. Record the file size, elapsed time, direction, destination, and number of concurrent transfers; repeat under comparable conditions before and after each change. Verify that the copy completed successfully and remove test data according to your organization’s policy.

Reading the result. A 100 GB file transferred in 80 seconds averages 1.25 GB per second, or about 10 Gbps, using decimal units. Measure the full elapsed time consistently; file size divided by time is an application average, not the Ethernet line rate.

Compare that result with the network test. If iperf3 improves but the file transfer does not, investigate source read speed, destination write speed, the transfer service, encryption, and CPU on both ends. In Task Manager or Performance Monitor, watch disk activity, memory pressure, and individual CPU usage during the copy. A busy disk or core is a clue to investigate, not proof by itself.

Where the application supports it, your IT team can test one transfer against several parallel transfers, or adjust the application’s own concurrency one step at a time. Some applications can pace or limit transfers to reduce contention with other work. Record the prior setting and compare completion time, latency, errors, and the effect on shared traffic; more parallelism or a lower rate will not always make the job finish sooner.

Research

What a file-transfer study found.

In a 2026 WLCG research preprint, one site’s network benchmark increased from 20 to 90 Gbps after tuning, while its file-transfer rate did not improve because storage was the limiting factor. Another site improved its actual file-transfer rate. The study used Linux research servers, not Windows; the practical lesson is to test the complete workflow on your own system rather than assume a benchmark gain will carry over.

For high-speed benchmarks, ESnet describes the multithreaded test streams introduced in iperf3 3.16. Compare one and multiple streams, then use the actual transfer application to judge whether the change helps your work.

Checklist

Questions before changing a setting.

  • Is the connection using the intended adapter, link speed, and route?
  • Are errors or discards increasing at the host or along the path?
  • Is the bottleneck CPU, storage, a VPN, the peer, or a shared link?
  • Which TCP profile and policies are actually in effect?
  • Does the adapter and driver support the proposed setting?
  • Can the team restore the previous value and reconnect if the link drops?

For additional troubleshooting methods, see latency, jitter, and packet loss and preparing for an Internet support request.

References

Sources and further reading.

Check the version and scope of each source before applying guidance to your device.

Microsoft

Adapter & TCP

Measurement

TCP & throughput

Prepared by Stealth Communications, a provider of business connectivity. These examples do not replace the documentation or operating policies for your system.