EMZETT.Speed (Networking)
In short: The data transfer rate a connection actually achieves — depending on bandwidth, latency and data loss.
In more detail: Unlike pure bandwidth (the theoretical upper limit), the measured speed describes what actually arrives under real conditions — influenced by network congestion, faulty packets that have to be requested again, or poor signal quality on radio connections.
In Depth
The motorway analogy
A useful analogy: bandwidth corresponds to the number of lanes on a motorway, latency to the time a single car needs for the route, and the perceived “speed” results from the interplay of both — many lanes are of little use if there’s constant congestion (data loss, overload), and an empty, fast road is of little use if it only has one lane (low bandwidth with many simultaneous users).
The four metrics in detail
Bandwidth (capacity) -> theoretical maximum, e.g. "100 Mbit/s line"
Throughput -> rate actually achieved under real conditions
Latency (ping) -> time for the round trip of a single packet
Jitter -> variation in latency between consecutive packets
Throughput is practically always below the nominal bandwidth — if only because of protocol overhead (every packet carries additional control data that doesn’t count as actual payload), but also because of network congestion at peak times or shared infrastructure with many simultaneous users (e.g. in cable networks, where several households share a line, unlike dedicated fibre connections).
Why different applications need different values
Different applications care about different values: a file download benefits almost exclusively from high bandwidth/throughput — whether the individual packets take 10 ms or 100 ms hardly matters, as long as enough data per second arrives in the end. Online gaming and video calls, on the other hand, react much more sensitively to latency and above all jitter — even with very high bandwidth, a connection with fluctuating latency feels “choppy”, because data packets arrive irregularly instead of evenly and the receiving application first has to put them back into the right temporal order (jitter buffer), which leads to noticeable delays or dropouts.
Why speed tests only tell half the truth
A classic speed test usually only measures bandwidth/throughput to a nearby test server under optimal conditions — it says little about how a connection actually feels during a video call with fluctuating latency or when used simultaneously by several family members in the same household. That’s why a single “speed figure” never tells the whole truth about the perceived quality of use — professional network diagnostic tools therefore also measure latency, jitter and packet loss separately instead of relying on a single number.
See also: Bandwidth, Latency, Data loss, Flow control