Stealth CommunicationsEngineering brief / 04
Technical guide • Network performance

Speed tests,
made useful.

How to run a test, understand the numbers, and make a useful comparison.

What does a speed test tell you?

A speed test measures data moving between your device and a test server at a particular time. It can show useful symptoms, but it does not measure every part of the Internet or identify a problem on its own.

Keep in mind

A low result can come from the device, Wi-Fi, office equipment, the network path, the test server, or a combination. The next comparison helps narrow it down.

If your business is experiencing an issue, contact Stealth support at any time: +1 212 232 2020 or support@stealth.net. You do not have to complete these tests first.

Start with the device.

  1. 01

    Choose the right connection

    For a circuit comparison, use a suitable wired device when practical. Wi-Fi measures the wireless link too; in dense NYC buildings, nearby networks, walls, and interference can affect results.

  2. 02

    Check the adapter

    Confirm that the device, adapter, port, and cable support the speed being tested. A 1 Gbps adapter cannot measure the full capacity of a 10 Gbps circuit. Your IT team can also check interface counters for errors and discards on the test adapter and on switches, routers, and firewalls along the path to the service handoff. Note whether the counters increase during the test; an old cumulative count alone does not establish a current problem.

  3. 03

    Note other activity

    Backups, file transfers, VPNs, and other users may affect the result. Coordinate testing with your IT team rather than interrupting business activity.

High-speed tests can transfer substantial data and compete with production traffic. Use approved endpoints and a suitable testing window.

Know where the test goes.

A nearby server can provide a useful view of a shorter path. A server farther away or on another network tests a different path and can produce a different result.

On-net testing to a server within your provider’s network can help assess that path. An off-net server adds interconnections and other networks to the measurement. Both can be useful; neither represents every destination your business uses.

Record the server name and location. If you are using Speedtest.net, you can choose a server before starting; Stealth Communications appears as a New York test server when available.

Four numbers to understand.

01

Download

Data arriving at your device from the test server, commonly reported in megabits per second (Mbps) or gigabits per second (Gbps).

02

Upload

Data sent from your device to the test server. It matters for cloud backups, file sharing, meetings, and other outbound traffic.

03

Latency

The time for a measurement to travel between endpoints, often shown as round-trip time in milliseconds. Check exactly what the tool measures.

04

Latency under load

Some tests measure delay while upload or download traffic is running. Increased delay can indicate queueing on the tested path; it does not identify the queue by itself.

Also note any packet loss or retransmissions the tool reports, when available. Interpret them in context; a missing measurement does not mean zero loss.

Keep the test conditions.

Record the device, wired or Wi-Fi connection, negotiated interface speed, test tool, server, time and time zone, direction, and result. If relevant, include IPv4 or IPv6 and whether a VPN was active.

Repeat the test when the issue occurs and, if useful, at a quieter time. To compare providers or periods fairly, keep the tool, server, device, and method as consistent as possible. A test result is a snapshot, not a guarantee of future performance.

Investigate differences. A fast nearby result and a slower distant result can reflect differences in paths, test servers, latency, congestion, or endpoints. More evidence is needed to identify the cause.

One connection or several?

Some tests use one data stream; others use several at once. A single-stream test describes how one connection performs on that path. Parallel streams can reveal aggregate throughput and may use more available capacity.

Both are useful. A single transfer or application may behave differently from eight simultaneous transfers. M-Lab’s NDT measures single-stream performance to an M-Lab server; its results should be read alongside the server location and method.

Browser tests and command-line tools each have limitations. Neither is automatically more accurate: compare what each test measures, the endpoints, and the device running it.

Testing with iperf3.

iperf3 measures throughput between a client and an iperf3 server. Use a server you operate or are authorized to test. The following examples use Stealth’s server and eight parallel TCP streams:

Client to server

Upload

iperf3 -c iperf3.stealth.net -P 8 -t 10
Server to client

Download

iperf3 -c iperf3.stealth.net -P 8 -t 10 -R

-P 8 uses eight streams; -t 10 runs for ten seconds; -R reverses the direction. To compare a single stream, use -P 1. iperf3 3.16 and later use a separate thread per stream. The server may be busy; its capacity and other traffic can limit a result.

Client and server summaries may differ because of buffering, timing, and data still in flight at the end. Examine both reported directions and the test conditions rather than treating the difference alone as measured packet loss.

Make sure the test can keep up.

At 10, 100 Gbps, and above, a modern computer alone is not enough. Both endpoints and the path need suitable interfaces, CPU, memory, operating-system network settings, and available capacity. Check for bottlenecks before interpreting a lower result as a circuit limit.

Purpose-built equipment can help with repeatable high-speed validation and testing different traffic patterns. Suitably equipped servers can also test at very high rates; the method depends on the question and the level of assurance needed.

What to share with support.

  • Company, service address, and a contact number.
  • What is affected, when it began, and a recent example with time zone.
  • Device and connection type, adapter speed, and whether a VPN was active.
  • Test tool, server, IP version if known, direction, time, and results.
  • Whether the issue affects one application, one device, or the office more broadly.

Call +1 212 232 2020 or email support@stealth.net. Please omit passwords, API keys, and private credentials.

About this guide.

Prepared by Stealth Communications, a provider of business connectivity. This guide explains measurement concepts; it does not establish the cause of an individual result or replace the applicable service agreement.

Further reading: ESnet iperf3 documentation; ESnet iperf3 FAQ; Measurement Lab NDT; and Microsoft’s network adapter performance guidance.

Published October 31, 2026.