Is latency another word for throughput?

No. Latency is a time interval; throughput is an amount delivered per unit time.

Can a network have high throughput and high latency?

Yes. A long path can sustain a large transfer while individual exchanges still take considerable time.

Does network monitoring reveal the cause of every slow application?

No. Server queues, storage, software and client processing can contribute, so communication measurements need to be connected with application evidence.

AI Glossary / Mathematics and optimization / Beginner

Network performance

Definition

Network performance describes how well a communication network carries data for a specified task and set of conditions. It includes measures such as throughput, delay, delay variation, packet loss and availability. No single number fully describes it: a network that transfers large files quickly can still provide a poor experience for interactive voice or remote control.

What it means

The relevant performance depends on what users are trying to do. A large dataset transfer needs sustained delivery capacity. A video conversation needs timely, reasonably consistent delivery. An AI service may depend on both: uploading an image requires data transfer, while a conversational response also depends on request delay and server processing. Network performance concerns the communication portion of that experience, not the model's reasoning quality or every cause of a slow application. Meaningful comparisons identify the path, direction, traffic type and measurement period.

How it works

Define an observable quantity before selecting a test. Throughput measures a rate under a stated counting convention; latency measures elapsed time between stated events; loss measures missing traffic relative to what was sent or expected. Delay variation describes how delays differ, but the exact statistic must be specified. Measurements may use active probes, passive observations or device counters, each with different coverage and limitations. Collect samples across representative conditions and summarize them with suitable distributions or percentiles. One-way timing requires attention to clock alignment, while round-trip measurements combine both directions and endpoint behavior. Neither should be silently substituted for the other.

Three practical examples

A remote team investigates disrupted calls by checking packet loss and delay variation during the affected periods, rather than relying only on a large-file speed test.
A data team measures sustained transfer rate between storage and a training environment to estimate how long dataset movement takes.
A web service separates connection and transfer timings from backend processing to understand whether a slow AI response comes mainly from the network, a queue or model execution.

Think of it this way

Think of a delivery service. Vehicle capacity resembles how much data can move, journey time resembles delay, inconsistent arrival times resemble delay variation, and missing parcels resemble loss. These qualities matter differently for moving furniture and delivering a hot meal. The analogy is limited because packet networks retransmit, share links and adapt sending rates in ways that do not map neatly onto physical deliveries.

Worked example

Suppose 1,000 test packets are sent during a defined interval and 990 arrive within the measurement's stated waiting limit. The observed loss fraction is 10/1,000 = 1%. Of the received packets, 950 have one-way delay of 20 milliseconds and 40 have delay of 200 milliseconds. Their mean delay is (950 × 20 + 40 × 200)/990, approximately 27.27 milliseconds. Using the nearest-rank convention, the 95th-percentile position is ceiling(0.95 × 990) = 941, so that percentile is 20 milliseconds. The 99th-percentile position is 981, giving 200 milliseconds. The average and 95th percentile alone conceal the slower tail. Separately, if 80 megabits of unique application data arrive over 10 seconds, application goodput is 8 megabits per second. These figures describe different aspects and should not be collapsed into one unexplained quality score.

Illustrative case study

In a fictional project, Juniper Studio investigates an intermittent delay in its online collaboration tool. Overnight transfers perform well, but staff report pauses during afternoon meetings. The team measures the affected path at relevant times and examines both network timing and application processing. It finds that an average across the whole day obscures short periods of poor responsiveness. The team tests a targeted change and repeats comparable measurements. The scenario illustrates diagnosis; it does not attribute a real outage or claim a measured improvement.

Common misconceptions and mistakes

A high advertised link rate is not a guarantee of high application throughput. A successful ping does not establish that every application protocol works, and a low average delay does not rule out damaging tail delays. Conversely, low throughput during a quiet period may simply mean little data was requested. Tests can also be limited by endpoint storage, processor load or the measurement tool. Compare like with like: different packet sizes, directions, test durations and traffic loads can produce different results without either result being wrong.

Business use

Translate user needs into measurable objectives and collect evidence at the points needed to diagnose them. For a conversational service, distinguish connection setup, first response delay and sustained streaming behavior. For transfers, define whether the metric counts application payload or lower-layer traffic. Record the time, endpoints, workload and measurement method with each result. Use controlled testing carefully so the test itself does not distort normal operation. Evaluate proposed upgrades against the actual bottleneck rather than assuming that more nominal bandwidth will solve every responsiveness problem.

Check your understanding

A network averages 27 milliseconds of delay, but some packets take 200 milliseconds. Is the average enough to judge an interactive application?

Answer: No. Tail delays, loss, delay variation and the application's requirements may determine whether the experience is acceptable. The measurement distribution matters.

Related terms

Latency
bandwidth
throughput
goodput
packet loss
quality of service

Learn next

create a small table of packet delays and compare mean, median and selected percentiles under a stated percentile convention. Then map each metric to a specific user activity and identify which endpoint or path measurements would help explain a poor result.

Sources

Sources: IETF RFC 2330, Framework for IP Performance Metrics, https://www.rfc-editor.org/rfc/rfc2330.txt ; RFC 5136, Defining Network Capacity, https://www.rfc-editor.org/rfc/rfc5136.txt ; RFC 1242, benchmarking terminology, https://www.rfc-editor.org/rfc/rfc1242.txt . These provide measurement and terminology foundations; the packet dataset and case above are original examples.

Previous: Network on a chip Next: Network sampling