A real SSH transfer measurement: results, method and limits

We measured a real Raspberry Pi-to-Windows private-network path on November 1, 2026 to demonstrate how a result depends on its method. The median of three short measured windows was 925.489 Mbps. This was an SSH transport diagnostic with compression disabled, not a PulseLAN application benchmark, a Wi-Fi comparison or an internet speed test.

Question and setup

The narrow question was: how quickly could this existing SSH session deliver and verify an 8 MiB window at that moment? The client was Windows running Python; the server was a Raspberry Pi. We did not independently inventory the intermediate interfaces, so this report does not label the path wired-only or claim a particular negotiated link rate. Addresses, host names and credentials are omitted.

Method that can be repeated

1. Establish one SSH connection with compression explicitly disabled. Generate a repeatable payload in memory so source storage is not the input.
2. Have the server wait for a client start request before each 8 MiB window. The client starts its timer before sending that request.
3. Read exactly 8,388,608 bytes and verify their SHA-256 digest. Stop the client timer only after the bytes have been read and hashed.
4. Use the first window as warm-up, then keep all three subsequent windows. Do not discard a slower measured window.
5. Calculate decimal Mbps as bytes × 8 ÷ seconds ÷ 1,000,000. Report the median along with every raw window.

Observed results

Download the raw result and method notes and the Python reproduction source. You need your own authorized SSH destination to reproduce it. The source is provided for inspection; the web page does not execute commands or probe your network.

Why the number is not a link-speed verdict

Each measured window was less than a tenth of a second. That makes this a short snapshot with sensitivity to buffering, scheduling and timing overhead. It includes the request, SSH encryption, Python reads and digest calculation. It does not isolate Ethernet capacity, TCP behavior, radio performance or the PulseLAN protocol. Repeated bytes were used, with SSH compression disabled. A different cipher, CPU load or test duration could change the result.

What we learned

The warm-up differed from the later windows, so reporting only the fastest number would conceal part of the experiment. The retained windows were close together in this run, but three short samples cannot establish stability over an evening or under competing traffic. The legitimate conclusion is limited: this particular transport path delivered these windows at these observed rates under these conditions.

How to investigate a slow file copy next

Keep the endpoints and direction fixed, then compare a longer generated-data test with the actual copy. If generated data is fast while a copy is slow, investigate storage, protocol, small-file overhead and security scanning. Do not replace a router from this example. Use our LAN measurement worksheet to record your own three-run results and compare one changed condition at a time.

References and authorship

The ESnet iperf3 reference explains directional and stream controls in another measurement tool; our SSH diagnostic is not iperf. Microsoft’s file-copy troubleshooting guide informs the distinction between network transport and storage. Prepared by the PulseLAN editorial team from the recorded run. See editorial standards for corrections and example labeling.