Diagnosing a Cloud Mac Network with Throughput, RPM, and MTU Baselines

When remote sessions start dropping frames or dependency downloads fluctuate unpredictably, do not reinstall the toolchain or draw conclusions from a single speed test. The Cloud Mac experience is affected by throughput, loaded latency, DNS, routing, and path MTU. The right approach is to standardize the test conditions, collect a repeatable baseline, and then use controlled comparisons to determine whether the issue lies with the client-side network, the transport path, or competing workloads on the remote machine.

Fix the Test Conditions Before Sampling

Network results are comparable only when the conditions are consistent. Record the macOS version, network interface, whether a VPN is in use, the test period, and the tasks running at the time. If the remote machine is downloading dependencies, synchronizing large files, or running a highly parallel build, the measurement reflects the network under workload and must not be mixed with idle results.

Establish an idle baseline first, then repeat the test while the actual workload is running. Run each test set at least three times and retain the median result rather than a single peak. Choose SoarMac nodes based on the configurations currently available in the console. When comparing regions, keep both the client-side network and the test target unchanged.

mkdir -p "$HOME/network-baseline"
cd "$HOME/network-baseline"

date -u
sw_vers
scutil --nwi
route -n get default
networkQuality -v | tee "networkquality-$(date +%Y%m%d-%H%M%S).log"

scutil --nwi identifies the interface actually carrying traffic, while route shows the default egress path. If wired, wireless, and tunnel interfaces are active at the same time, relying only on the menu bar connection status can easily lead to the wrong path being identified.

The purpose of a baseline is not to prove that the network is “fast.” It is to obtain data that can be compared before and after a failure, at idle and under load, and over direct and tunneled connections.

Evaluate Throughput and Loaded Responsiveness Together

networkQuality reports download capacity, upload capacity, and responsiveness. Large-file synchronization depends more heavily on sustained throughput, while remote desktops, SSH input, and debugging operations depend more on round-trip responsiveness under load. A high bandwidth figure does not necessarily mean that interactive use will be smooth.

Detect Queueing with Parallel Sampling

Open two Terminal windows. Run networkQuality -v in the first, and continuously ping the same target from the second:

export TARGET_HOST="your-controlled-endpoint"
ping -c 40 "$TARGET_HOST" | tee ping-under-load.log

Run the test once while idle, then repeat it while uploading a large file. Compare the average latency, maximum latency, and range of variation. If idle latency is stable but rises significantly during the upload, the client-side uplink is commonly saturated and packets are queueing at the egress point. In that case, limiting the synchronization task’s concurrency or bandwidth is usually more effective than replacing remote development tools.

Isolate DNS and Routing

A failed dependency download is not necessarily a bandwidth problem. First inspect the resolvers actually used by the system instead of relying only on the Network settings interface:

scutil --dns | tee dns-state.log
dscacheutil -q host -a name "$TARGET_HOST"
route -n get "$TARGET_HOST" | tee target-route.log

scutil --dns may show multiple resolver sets and their matching domains. If the command line can reach an IP address but cannot resolve the hostname reliably, address DNS first. If resolution works but traffic enters an unexpected tunnel interface, inspect the routing priority. Save the output before changing the configuration, then retest with the same commands afterward so that multiple variables are not changed at once.

Verify the Port, Not Just Ping

Some targets do not respond to ICMP, so a failed ping does not automatically mean the service is unreachable. For a target you control, test the actual application port:

nc -vz -G 5 "$TARGET_HOST" 443

If the port connection succeeds while ping receives no response, at least the TCP connection path is available. If the port times out, continue checking routing, firewall policies, and the tunnel egress. Do not rule out intermittent faults based on a single successful browser request.

Check the Path MTU with Increasing Payloads

A VPN or other encapsulation reduces the payload that can be carried. Typical symptoms include small requests working while large-file transfers stall, or a connection being established but making no progress for an extended period. The macOS ping command can set the do-not-fragment flag and vary the payload size:

export TARGET_IPV4="192.0.2.10"

for size in 1200 1300 1400 1450 1472; do
  echo "payload=$size"
  ping -D -c 3 -s "$size" "$TARGET_IPV4"
done

Replace the example address with an IPv4 target you control. If smaller payloads succeed consistently while larger ones repeatedly fail, record the threshold and repeat the test over both direct and tunneled connections. Do not immediately reduce the MTU of the remote interface. First identify which segment of the path imposes the limit; otherwise, the change may conceal the actual problem and affect other connections.

Create a Reviewable Acceptance Record

A complete record should include the system version, interface, default route, DNS state, idle and loaded networkQuality results, ping results for the same target, and the MTU threshold. Redact sensitive addresses and internal domain names before sharing, but preserve timestamps, command parameters, and test conditions.

After applying a fix, rerun the tests in the original order. Do not switch targets or keep only the best-performing run. Acceptance criteria can include the following: results are recorded both at idle and under load; there is no sustained high latency during remote interaction; domain-name resolution and application-port connections succeed consistently; large-file transfers complete reliably; and the differences between direct and tunneled connections are explained. Only then are the findings suitable for a support ticket or team runbook, while also providing a baseline for direct comparison during the next incident.

Frequently asked questions