A faster path
for your Mac.

01 / Before changing anything

Measure the current experience.

Record the macOS version, Mac model, adapter, negotiated speed, cable, switch port, test destination and time. Use a wired connection, confirm the route takes the intended interface, and use a server on a separate host across a network path representative of the workload.

Use a test endpoint you are authorized to use. Record round-trip latency before and during the transfer where practical, plus receiver throughput, retransmissions, interface errors, CPU load and concurrent activity. Repeat comparable tests in both directions. An Internet path, firewall, VPN, destination or the Mac itself can limit a result.

For example, with iperf3 installed, permission to use the destination and a separate Mac across the intended network path:

iperf3 --version
ping -c 5 iperf3.stealth.net
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

The first iperf3 test uses one TCP stream; the second uses eight. -R reverses the direction, so the server sends to the Mac. Compare the aggregate receiver results as well as individual streams. ICMP ping can be filtered or treated differently, and idle latency can differ from latency under load. A busy or unavailable endpoint does not establish a circuit fault. Repeat the same measurements after any change; consult the speed-test guide for 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 a Mac, use the executable name installed on that system if it differs. Threading helps the test use available cores; it does not make one TCP stream use eight cores or guarantee a higher result.

02 / The local connection

Check the port from end to end.

Open System Settings → Network, select the Ethernet service, then open Details → Hardware. Apple recommends automatic hardware settings unless your administrator supplies specific settings. Menu names differ by macOS version and adapter.

Confirm the Mac’s built-in port or USB/Thunderbolt adapter supports the intended speed. A dock’s connection to the Mac, its other attached devices, the cable, and the switch port can each limit throughput. A nominal 10 Gbps adapter is not proof of 10 Gbps application throughput. If practical, compare the same adapter directly and through the dock.

To identify the BSD interface name, an authorized user can run the read-only command below. It lists hardware ports and identifiers; review the output before sharing it.

networksetup -listallhardwareports

Use the interface corresponding to the Ethernet service, not an assumed en0. Depending on the hardware, en0 may refer to Wi-Fi.

03 / Evidence

Check the interface, not just the speed test.

In Terminal, replace enX with the actual Ethernet interface identified above. These commands display local interface information; they do not change settings.

ifconfig enX
netstat -I enX -b

Record the link state and any reported media, MTU, packets, errors, and drops. Fields, counters, and permissions differ by adapter and macOS release. Compare two readings over a known interval, including during the test, and check the connected switch port and other interfaces through the handoff. A historical total or a counter unavailable from one adapter does not establish a current fault. Output may contain IP or hardware addresses; redact it appropriately.

macOS also uses network memory buffers called mbufs. The read-only command netstat -m reports network memory statistics on supported releases. When available, compare observations over time and interpret allocation failures or waits with the documentation for your release; the amount in use alone does not prove a shortage. Do not assume a FreeBSD or Linux buffer limit applies to macOS.

In Activity Monitor → Network, watch aggregate data and packet activity while a test runs. Apple’s view helps show whether the Mac is busy, but does not by itself identify where a network bottleneck occurs.

04 / TCP & distance

Why does a distant transfer need room?

TCP can have data in flight while it waits for acknowledgments. The bandwidth-delay product estimates the amount: target rate in bits per second multiplied by round-trip time in seconds, divided by eight.

These are theoretical estimates for each direction of a path at the target rate, not buffer settings or guaranteed speeds. For example, 10 Gbps × 0.040 seconds ÷ 8 = 50,000,000 bytes. With multiple streams the total can be distributed across connections; one stream and eight streams are different tests.

TCP congestion control, available receive window, packet loss, the application and the other endpoint all affect throughput. A larger buffer ceiling cannot repair loss or a slow destination. Actual memory use depends on active connections and workload.

Inspect these values on macOS releases where they are available:

sysctl net.inet.tcp.sendspace
sysctl net.inet.tcp.recvspace
sysctl net.inet.tcp.autosndbufmax
sysctl net.inet.tcp.autorcvbufmax
sysctl net.inet.tcp.win_scale_factor

The first two are initial TCP send and receive buffer settings. The next two are limits used by TCP buffer auto-sizing; they are not necessarily allocated memory or the actual window of a connection. As an illustration, a Mac could report 131,072 bytes for each initial setting and 4,194,304 bytes for each auto-sizing limit. Those readings alone do not establish a problem: actual buffers, the path and the application matter. An application can also set its own socket buffers, affecting automatic sizing for those sockets.

About window scaling: In Apple’s published XNU source for one macOS release (xnu-11417.121.6), win_scale_factor is a minimum requested receive-window scale, and the kernel can request a higher scale to accommodate the receive buffer maximum. A value of 3 does not itself cap a connection at 512 KiB, and changing it to 8 is not automatically necessary. The scale is negotiated when a TCP connection starts; test with new connections after a change. Negotiation depends on both endpoints, and behavior may change with the release. Review the source and settings for the system being tested.

05 / A controlled experiment

When would a larger ceiling help?

Consider a temporary test when measurements suggest a single TCP stream is constrained by the receiving Mac’s buffer or window, both endpoints are capable, and the path is otherwise healthy. For context, a 10 Gbps path with a 10 ms round trip has a bandwidth-delay product of 12.5 MB. ESnet describes a 32 MiB auto-buffer example for high-speed macOS; it is an experiment, not a universal setting. It may still be too small for other rates or distances.

This example changes only the Mac’s receive auto-buffer ceiling and focuses on iperf3 -R, where the Mac receives data. It applies only when the current receive limit is exactly 4,194,304 bytes. Capture the value in the same Terminal session and retain the output. If the key is unavailable or the capture fails, stop.

unset mac_original_receive
mac_original_receive="$(sysctl -n net.inet.tcp.autorcvbufmax)" &&
printf 'receive=%s\n' "$mac_original_receive"

If the value matches the example, the following guarded command tries to raise the receive ceiling to 32 MiB for the current running system. If the write is denied or the key is unavailable on your release, stop; do not bypass system protections or management policy.

if [ "${mac_original_receive-}" = 4194304 ] &&
   [ "$(sysctl -n net.inet.tcp.autorcvbufmax)" = "$mac_original_receive" ]; then
  sudo sysctl -w net.inet.tcp.autorcvbufmax=33554432
else
  printf '%s\n' 'No change: the recorded or current value differs.'
fi

Verify the current value with sysctl net.inet.tcp.autorcvbufmax, then repeat the reverse-direction baseline tests and actual application workload with new TCP connections. More permitted buffer space can increase memory used across concurrent connections; monitor memory pressure as well as throughput and latency. A higher ceiling does not guarantee the system or application will use it.

To roll back in the same Terminal session, restore the saved value. The guard avoids overwriting a value that another administrator or process has changed since the trial. If the guard does not run, inspect the current value and resolve the discrepancy before making further changes.

if [ "${mac_original_receive-}" = 4194304 ] &&
   [ "$(sysctl -n net.inet.tcp.autorcvbufmax)" = 33554432 ]; then
  sudo sysctl -w "net.inet.tcp.autorcvbufmax=$mac_original_receive"
fi
sysctl net.inet.tcp.autorcvbufmax

Confirm that the final value matches the recorded baseline. These commands do not make a persistent configuration. Keep the trial only if measured improvement and resource use justify it, and use the organization’s supported change process for any permanent decision.

A second buffer example

What if the Mac is sending?

For a separate test, suppose a single upload is limited by the Mac’s automatic send-buffer ceiling. With your company’s IT team, first check the application, peer, loss, and memory budget. The following is an illustrative temporary change from 4 MiB to 32 MiB, only when the current value is exactly 4 MiB and your macOS release permits it. It is not a default to apply to all systems. Test this separately from the receive-buffer trial, so the results are understandable.

In one Terminal session, record the original value and keep the output in your change record:

unset mac_original_send
mac_original_send="$(sysctl -n net.inet.tcp.autosndbufmax)" &&
printf 'send=%s\n' "$mac_original_send"

If the read fails, the value differs, or you cannot confirm memory and system requirements, stop. Otherwise, the following checks the value again and attempts the change:

if [ "${mac_original_send-}" = 4194304 ] &&
   [ "$(sysctl -n net.inet.tcp.autosndbufmax)" = "$mac_original_send" ]; then
  sudo sysctl -w net.inet.tcp.autosndbufmax=33554432
else
  printf '%s\n' 'No change: the recorded or current value differs.'
fi

If the setting is absent or a write is denied, stop without bypassing system protections. Confirm the result with sysctl net.inet.tcp.autosndbufmax, then repeat the same upload test using a new connection and observe memory pressure and other workloads. A higher limit does not ensure that an application will use it.

To restore the recorded value in the same Terminal session, use the guard below. If the current value has changed in the meantime, investigate with your IT team before restoring it.

if [ "${mac_original_send-}" = 4194304 ] &&
   [ "$(sysctl -n net.inet.tcp.autosndbufmax)" = 33554432 ]; then
  sudo sysctl -w "net.inet.tcp.autosndbufmax=$mac_original_send"
fi
sysctl net.inet.tcp.autosndbufmax

Check the final value against the recorded original. This runtime command does not configure persistence; use your organization’s change process for any lasting decision.

06 / Hardware settings

When should you change MTU or link settings?

Keep automatic speed and duplex unless the network administrator and equipment documentation call for a specific configuration. A mismatched setting can interrupt service or reduce performance. Confirm the negotiated rate on both ends and check for an adapter or cable issue before changing it.

A larger MTU may reduce per-packet overhead in a designed network, but it is not a universal Internet speed setting. Verify the complete intended path, device support, and path-MTU behavior first; mismatches can cause packet loss or applications that partially fail. Do not enable jumbo frames on a production network solely because a benchmark guide suggests them.

07 / The Mac and its workload

Look for the next limit.

During a controlled test, review CPU, memory pressure, and disk activity in Activity Monitor. High CPU on a test process, encryption, VPN software, inspection, a slow storage device, or a busy destination can cap throughput even when link speed looks correct. Do not disable security software to obtain a better number without an approved security and test plan.

A different adapter driver or firmware can change behavior. Check the hardware manufacturer’s support guidance and your organization’s update process. Advanced offload and queue controls vary by product; disabling them all is not a general performance improvement. Compare one supported change at a time.

08 / Plan and retest

Make one change, then measure.

1. 01

   Preserve the baseline

   Record the current values, connected devices, link status, and test results. Keep a way to access the Mac if the network setting is wrong.

2. 02

   Choose a supported adjustment

   Use the Mac or adapter documentation for the observed bottleneck. Agree on a maintenance window and a rollback with the responsible team.

3. 03

   Compare

   Repeat the same tests in both directions and watch latency, errors, CPU and applications as well as throughput. Restore the recorded values if the change does not help or causes problems.

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.

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 Activity 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 Macs; 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

Before you call it a network limit.

• Is the test using the intended Ethernet adapter, port, and speed?
• Are the cable, switch port, dock, and destination capable of the workload?
• Are errors or drops increasing during the test anywhere along the local path?
• Is latency, loss, CPU, storage, VPN processing, or the destination limiting the result?
• Was each proposed change approved, recorded, tested, and reversible?

For a broader comparison, see wired Ethernet vs. Wi-Fi and latency, jitter, and packet loss.

Related guides

Working with another system?

Explore high-speed network tuning for Linux, FreeBSD, and Windows.