This is a network bandwidth testing tool written in Rust, designed specifically to saturate 10Gbps XGS-PON/10G-EPON fiber internet connections.
Results depend on server selection, connection count, CPU capacity, and network conditions. Browser and CLI results can differ because they use different servers and measurement methods.
This tool addresses these bottlenecks through the following architectural decisions:
- Rust & Tokio: Utilizes the Tokio asynchronous runtime to handle thousands of concurrent tasks with minimal memory overhead.
- Rustls TLS Engine: Implements the
rustlslibrary for user-space TLS processing, with certificate verification and hostname-preserving connections pinned to the selected IPv6 address. - Forced HTTP/1.1: Deliberately disables HTTP/2 to force the operating system to open distinct, parallel TCP sockets for every download stream.
- Mimalloc: Integrates the Microsoft Mimalloc memory allocator to reduce heap fragmentation and locking during high-frequency buffer writes.
- Streaming bodies: Discards received body chunks without accumulating the download in memory and batches byte-counter updates.
- Rust Toolchain: A working installation of the Rust compiler and Cargo.
- IPv6 Connectivity: This tool requires IPv6 to be enabled and working on your system.
- Windows Users: This tool is highly optimized for Windows but works on Linux/macOS. On Windows, ensure your "Receive Window Auto-Tuning Level" is set to
normal.- Check current status:
netsh interface tcp show global - Enable if disabled:
netsh interface tcp set global autotuninglevel=normal
- Check current status:
- Build (or download pre-built) the project in release mode (debug builds will significantly limit throughput).
cargo build --release- Run the tool directly or by using
cargo. Tuning parameters will vary based on your hardware and network latency.
cargo run --release -- --time 10| Argument | Default | Description |
|---|---|---|
-s, --streams |
automatic | Set a fixed number of streams per server, disabling connection tuning. |
-c, --count |
8 | Maximum number of unique Netflix OCA servers available to the test. |
--chunk-size |
automatic | Set a fixed request size in MiB, disabling chunk-size tuning. |
--time |
10 | Measurement duration in seconds, after warm-up. |
--warmup |
0 | Optional extra warm-up before the timed test, in seconds. |
-v, --verbose |
off | Show auto-tuning setup and connection/chunk-size updates. |
By default, the app tunes total download connections during --time, starting with four connections spread across the selected servers. Every two seconds it doubles the count if the previous increase improved throughput by more than 5%. If the increase did not help, it returns to the previous count and waits six seconds before trying again. Automatic mode caps connections at 64 total and eight per available server. It stops launching experiments when fewer than two seconds remain. --count controls the candidate server pool; the number of active servers grows with the connection count. This is a bounded search, not a guarantee of optimal settings, especially in short or noisy tests.
Chunk size adapts independently per stream, starting at 64 MiB and targeting roughly two seconds of data per request. After successful requests, sizes change by at most a factor of two, within 16–1024 MiB; small changes are ignored to avoid oscillation. Updates apply to the next request without interrupting downloads. Bodies are streamed, so the request size is not an allocated buffer size. This heuristic limits request turnover; it does not benchmark every chunk size or guarantee an optimal size. Explicit --chunk-size fixes the size independently of connection tuning.
Server discovery happens before the timer; tuning and download ramp-up happen within it. Use --time 20 for more tuning time, or --streams 4 --count 8 to force the previous fixed 32-connection configuration.
The display reports throughput at approximately one-second intervals. The final result is the highest sampled throughput (peak), excluding any explicitly requested warm-up. Failed requests and interrupted streams are reported; HTTP error bodies are not counted. These results are not the same estimator as Fast.com’s displayed speed.
To consistently find the lowest-latency servers (which is critical for 10Gbps throughput), the tool maintains a local cache file named server_cache.json.
-
Accumulation: Every run fetches fresh server URLs and caches up to 100 unique hostnames. Fresh signed URLs replace cached URLs for the same host.
-
Optimization: Over time, this builds a large pool of candidate servers. On each run, the tool checks TCP latency and performs a small HTTPS download against cached and fresh servers. It excludes expired or rejected URLs, then picks the lowest-latency N unique hosts.
-
Benefit: Successive runs may yield better speeds as the tool discovers and remembers the specific servers that have the best peering with your ISP.
I used the following configuration to reach 8.01 Gbps on a residential 10Gbps 10G-EPON connection. This effectively saturates the physical limit of both XGS-PON and 10G-EPON standards after protocol overhead.
cargo run --release -- --streams 4 --count 8
Note on Stability: At these extreme speeds, you may observe a rapid drop-off after the peak. This is typical behavior caused by TCP Congestion Control (reacting to a dropped packet) or NIC Thermal Throttling. Ensure your 10G network card has adequate cooling.
This tool is an unofficial client and is not affiliated with or endorsed by Netflix. It accesses the Fast.com API using automated means.
Use with caution: This tool is capable of opening hundreds of concurrent high-bandwidth connections. Running this tool aggressively or repeatedly may be interpreted as a Denial of Service (DoS) attack by network providers or Netflix, potentially leading to IP bans or ISP service termination. The author is not responsible for any consequences resulting from the use of this tool.
MIT License