The short version
Why can a fast connection feel slow?
Bandwidth describes how much data a connection can carry. Latency describes how long data takes to travel; jitter describes changes in delay; and packet loss occurs when packets do not arrive as expected. Each can affect the work people do, even when the circuit has plenty of capacity.
Identify the affected application, location, and time. Compare measurements to the destination and path involved, then look for changes from normal.
A measurement is evidence about a particular test, not a verdict on the whole network. The destination, protocol, direction, and conditions all matter.
01 / Latency
How long does a response take?
Latency is delay between defined points. It is commonly measured in milliseconds (ms). A ping usually reports round-trip time (RTT): the time for a probe to reach a destination and its reply to return, including the destination’s response processing. It does not measure one-way delay directly.
Distance, routing, congestion, Wi-Fi, equipment, and the destination can all influence delay. Lower latency can make an interactive session feel more immediate. A nearby server may respond differently from a cloud application in another region.
02 / Delay variation
Does the delay stay consistent?
Jitter is a general term for variation in delay. Applications and test tools calculate it in different ways, so compare figures only after checking the method and measurement period.
For a simple illustration, ping replies of 20, 21, 19, and 20 ms are fairly consistent. Replies of 20, 80, 22, and 100 ms vary much more. This comparison shows variation; it is not a standardized jitter calculation.
Voice, video, and interactive applications can be sensitive to changing arrival times. They may use buffers to compensate, adding delay when variation is high.
03 / Packet loss
What happens when packets do not arrive?
When packets are lost, applications may retransmit data or work around the missing information. Transfers can slow; a call may have gaps, frozen video, or distortion. The effect depends on the protocol, the pattern of loss, and the application.
Suppose a ping sends 100 probes and receives 98 replies. That is 2% unanswered probes for this test. It does not prove exactly 2% of application traffic was lost: a request or reply may have been dropped, delayed, filtered, or rate-limited. A small sample can also miss short-lived problems.
A device that does not answer ping may still provide a working application. Similarly, a successful ping alone does not establish that an application is healthy.
04 / The working day
Why do these measurements matter?
Calls and meetings
Delay affects conversation; variation and loss can cause gaps, artifacts, or frozen video.
Cloud and remote desktops
Interactive work can feel sluggish when each action takes longer to reach the service and return.
Large transfers
Loss, round-trip time, TCP behavior, and host capacity can limit throughput even on a high-speed circuit.
AI tools
Network delay matters, especially for interactive or repeated requests. Model processing, service load, and the local network also affect total response time.
There is no universal good number for every destination. Use the application provider’s guidance, a comparable baseline, and the business’s requirements. The bandwidth planning guide addresses capacity; understanding an Internet SLA explains contractual measurement boundaries.
05 / Start with a baseline
Run a small, repeatable test.
Use a destination you operate or are authorized to test. Begin from a wired computer where practical, record the time and time zone, and note the application symptoms. Test from the affected location and, where useful, from another location or device for comparison.
Ping
ping -n 20 apple.comSends 20 echo probes and reports replies and round-trip times.
Ping
ping -c 20 google.comUse an approved destination relevant to the issue you are investigating.
What a ping looks like.
$ ping -c 4 apple.com
PING apple.com (2620:149:af0::10) 56 data bytes
64 bytes from icloud.com (2620:149:af0::10): icmp_seq=1 ttl=62 time=0.763 ms
64 bytes from icloud.com (2620:149:af0::10): icmp_seq=2 ttl=62 time=0.778 ms
64 bytes from icloud.com (2620:149:af0::10): icmp_seq=3 ttl=62 time=0.750 ms
64 bytes from icloud.com (2620:149:af0::10): icmp_seq=4 ttl=62 time=0.750 ms
--- apple.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3072ms
rtt min/avg/max/mdev = 0.750/0.760/0.778/0.011 ms
$ ping -c 4 google.com
PING google.com (2607:f8b0:4006:823::200e) 56 data bytes
64 bytes from pnlgaa-ba-in-x0e.1e100.net (2607:f8b0:4006:823::200e): icmp_seq=1 ttl=122 time=0.722 ms
64 bytes from pnlgaa-ba-in-x0e.1e100.net (2607:f8b0:4006:823::200e): icmp_seq=2 ttl=122 time=0.725 ms
64 bytes from pnlgaa-ba-in-x0e.1e100.net (2607:f8b0:4006:823::200e): icmp_seq=3 ttl=122 time=0.729 ms
64 bytes from pnlgaa-ba-in-x0e.1e100.net (2607:f8b0:4006:823::200e): icmp_seq=4 ttl=122 time=0.734 ms
--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3070ms
rtt min/avg/max/mdev = 0.722/0.727/0.734/0.004 mstime is the round-trip time for each reply, in milliseconds.
Packet loss here means no replies were missing from these four probes. It does not establish an application’s loss rate.
min/avg/max/mdev summarizes the replies received. The mdev value is the standard deviation of those round-trip times; a larger value indicates more variation in this sample.
The mdev figure describes variation in these ping round trips; it is not the same as an application’s jitter measurement. The names shown after “from” are reverse-DNS names for the responding addresses. They can differ from the name queried and do not by themselves identify the application serving the request.
Repeat at a quiet time and during the issue. Check which IP address and address family were used; a name can resolve to different servers, and IPv4 and IPv6 may follow different paths. Record the number of probes and the observed range, not just an average.
Some destinations do not answer ICMP ping, or answer it differently under load. If appropriate and authorized, compare with application telemetry or a TCP-based test to the actual service. Do not run repeated high-rate probes against systems without permission.
06 / Follow the path
Traceroute and TCP traceroute.
Traceroute sends probes with gradually increasing hop limits. Routers that respond help show a path toward the destination, with a response time for each responding hop. Asterisks or missing rows mean a reply was not received; a router may filter, deprioritize, or limit diagnostic responses while continuing to forward traffic.
Traceroute
tracert -d example.com-d skips reverse-name lookups for hops.
Traceroute
traceroute example.comOn some systems the tool must be installed. Options and default display vary by implementation.
Windows tracert uses ICMP; traceroute implementations can use different probe types. For a permitted HTTPS service, TCP traceroute sends TCP probes toward a chosen port. On a system with tcptraceroute installed, an example is:
tcptraceroute example.com 443Availability and required permissions vary by system. Test only a service you are authorized to probe.
TCP probes can be useful when a network handles ICMP and application traffic differently, but a TCP response does not prove that HTTPS or the application works. Intermediate hops still generally respond using ICMP. Different probe types, routing, and return paths can produce different results.
Following TCP to port 443.
apple.com. The hostname resolved to 17.253.144.10 for this test. The local interface and temporary source port are omitted; the destination, hop addresses, and times are from the recorded output. This is a snapshot, not a live measurement.$ tcptraceroute -n -q 1 -w 1 -m 8 apple.com 443
Tracing the path to apple.com (17.253.144.10)
on TCP port 443 (https), 8 hops max
1 207.251.66.11 0.143 ms
2 198.32.160.224 0.820 ms
3 17.1.2.192 1.299 ms
4 17.1.2.181 1.321 ms
5 17.0.18.215 0.867 ms
6 17.253.144.10 [open] 0.849 msPort 443 selects the destination TCP service for the probes.
Hop addresses and times show responses to individual probes, with a round-trip time for each.
[open] indicates a TCP response consistent with an open port at that moment; it does not confirm the website loaded.
The address and path may change between tests. Intermediate responses are generally ICMP even when the probes use TCP.
Reading a traceroute.
$ traceroute -q 1 -w 1 -m 8 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 8 hops max
1 207.251.66.11 0.142 ms
2 206.252.195.106 0.191 ms
3 192.178.106.135 1.341 ms
4 216.239.43.63 0.856 ms
5 8.8.8.8 0.389 msHop number identifies where a responding device appears in this trace.
Time in milliseconds is the round trip for that hop’s probe and reply. These are separate measurements.
Destination is the final responding address. One successful trace does not establish continuous availability.
A later hop can show a lower time because each row is measured separately. An asterisk, when present, means a probe did not receive a reply in time; it does not alone prove an outage.
07 / Measure the path over time
How to read MTR.
MTR combines path discovery with repeated probes, reporting each responding hop’s round-trip response times and unanswered probes. If installed and permitted, this runs a bounded report of 50 cycles:
mtr -r -w -c 50 example.comRuns approximately 50 seconds at the usual one-second interval, plus any wait for final replies.
mtr -T -P 443 -r -w -c 50 example.comTCP mode may require additional permissions and only tests the selected service port.
The examples below are illustrative. Each row summarizes replies to 50 separate probes, not the journey of the same packet through every line.
| Hop | Example A: unanswered probes | Example B: unanswered probes |
|---|---|---|
| 1 | 0% | 0% |
| 2 | 60% | 0% |
| 3 | 0% | 4% |
| Destination | 0% | 4% |
In example A, hop 2’s missing replies do not by themselves show transit loss: later hops and the destination responded to their probes. That router may limit diagnostic replies. In example B, unanswered probes continue to the destination, which merits further investigation. The matching percentages do not prove that hop 3 or its link is at fault.
Hop times are round trips to each responding device, not one-way link delays. Do not subtract adjacent rows to calculate a link’s latency. Probe filtering, load balancing, path changes, and different return paths can complicate the picture. A destination can limit or ignore probes too, so correlate the trace with application results and other measurements.
MTR to an API endpoint.
api.openai.com, which resolved to 172.66.0.243 for this test. This short, dated snapshot is not a live measurement.$ mtr -4 -T -P 443 -r -n -w -c 5 -m 16 -G 1 -Z 2 api.openai.com
Start: 2026-11-01T00:53:30+0000
HOST: millennium2 Loss% Snt Last Avg Best Wrst StDev
1.|-- 207.251.66.11 0.0% 5 0.2 0.2 0.2 0.3 0.0
2.|-- 207.251.66.12 0.0% 5 0.2 0.3 0.2 0.3 0.0
3.|-- 206.82.104.31 0.0% 5 8.8 9.3 7.7 12.8 2.0
4.|-- ??? 100.0 5 0.0 0.0 0.0 0.0 0.0
5.|-- 162.158.61.133 20.0% 5 2.5 2.6 1.7 3.9 0.9
162.158.61.125
162.158.61.60
6.|-- 172.66.0.243 20.0% 5 1.7 1.4 1.1 1.7 0.3Snt and Loss% show the probe count and unanswered responses. With five probes, one unanswered response is 20%.
Hop 4’s question marks mean no replies were received from that hop. Later hops responded, so this row alone does not establish a forwarding outage.
Last, Avg, Best, and Wrst are round-trip response times in milliseconds for replies received. StDev summarizes their variation.
The destination’s 20% represents one unanswered TCP probe in this small sample, not measured API request loss or proof of an application problem. The extra addresses at hop 5 are other responders recorded at that hop; they do not identify which responder handled each probe. DNS answers, routes, and responses can change. A TCP response does not establish API or model availability.
08 / High-speed throughput
Testing from 10 Gbps to 800 Gbps.
Ping and traceroute do not measure the available throughput of a connection. For a controlled capacity test, iperf3 sends traffic between a client and an iperf3 server. Multiple TCP streams can help exercise high-capacity paths; -P 8 starts eight parallel streams. It does not guarantee that any particular rate will be reached.
For an authorized test to Stealth’s server, these commands test each direction separately:
iperf3 -c iperf3.stealth.net -P 8 -t 10Sends from your client toward the test server.
iperf3 -c iperf3.stealth.net -P 8 -t 10 -R-R reverses the test direction. The server must be reachable and available.
Reading an iperf3 result.
$ iperf3 -c iperf3.stealth.net -P 8 -t 10
Connecting to host iperf3.stealth.net, port 5201
[ 5] local [address redacted] port 52774 connected to 2001:458:20:100::210 port 5201
[Individual streams and interval rows omitted]
[ ID] Interval Transfer Bitrate Retr
[SUM] 0.00-11.16 sec 244 GBytes 188 Gbits/sec 0 sender
[SUM] 0.00-11.16 sec 244 GBytes 188 Gbits/sec receiver
iperf Done.SUM combines the eight parallel streams; the sender and receiver each report their totals.
Bitrate is the observed aggregate for this local test. It is not the speed of a physical link.
Retr reports sender TCP retransmissions; zero here describes this test alone.
The requested duration was 10 seconds; the reported result covers 11.16 seconds. Client version: iperf 3.20+. To measure a network connection, run the client and server on separate machines across the path being tested.
At 10 Gbps, ten seconds can transfer roughly 12.5 GB of payload in one direction; at 800 Gbps, roughly 1 TB. Actual totals vary. A test can consume shared capacity and affect production applications, so coordinate with the network team and the server operator, select a suitable window, and follow the server’s test policy.
Both endpoints, interfaces, CPU, memory, software, firewall, and the full path must be capable of the target rate. A 10G or faster interface on one end is not enough. At hundreds of gigabits per second, a single host or server may be the limiting factor; an 800G assessment may require multiple capable hosts, parallel test endpoints, or dedicated test equipment. Record client and server versions and monitor system and interface counters.
iperf3 versions from 3.16 use one thread per stream; older versions have different CPU characteristics. Compare the receiver’s result, the sender’s retransmissions, and the test conditions. Different streams can follow different paths, and a multi-stream result does not establish single-flow performance. See the Internet speed-test guide for further testing context.
09 / Turn results into action
What should you send to support?
Check the local side as well as the Internet path. Compare a wired device with Wi-Fi, review utilization and error or discard counters on the adapter and equipment through the circuit handoff, and check firewall and device load. A full link can increase delay; a quiet link does not rule out a problem elsewhere.
- Affected application, users, location, and the symptoms they observed.
- Start and end times with the time zone, plus whether the issue is ongoing.
- Source and destination, the resolved IP address, and whether the test used IPv4 or IPv6.
- Probe type, port where relevant, sample count, and complete ping, traceroute, or MTR output.
- Comparison from another device, location, or time; note wired, Wi-Fi, and VPN use.
- Relevant interface utilization, error and discard counters, and any recent changes.
Share logs through an approved channel: traces can reveal internal addresses and network details. For Stealth service, contact support@stealth.net or +1 212 232 2020.
About this brief
Sources and further reading.
These original standards, tool references, and application guides explain the measurements and methods discussed above. Their definitions and test environments differ; compare results using the same method and scope.
Delay, variation and loss
- IETF RFC 7679One-way delay metric and measurement considerations
- IETF RFC 3393IP packet delay variation
- IETF RFC 7680One-way packet loss metric
- IETF RFC 6349Framework for TCP throughput testing
Commands and interpretation
- MTR projectPath probing and intermediate-router response limits
- MTR manualReport mode, probe types, ports, and options
- Microsoft: tracertWindows path-tracing command and output
- ESnet: iperf3 FAQParallel streams, host limits, and multithreading
Meeting quality
- Microsoft Teams: Meeting troubleshootingInvestigating meeting quality and network metrics
- Zoom: Meeting statisticsApplication-side network and media measurements
Prepared by Stealth Communications, a provider of business connectivity. The examples are educational and do not replace an investigation of the affected path or application.