Three different questions
When people say a connection is “fast” or “bad,” they usually mean one of three different things. Bandwidth asks how much data can flow. Latency asks how long data takes to arrive. Packet loss asks how much of it never arrives at all. A connection can score well on one and poorly on another, and the symptoms differ.
Bandwidth: how much
Bandwidth is the maximum rate at which data can be carried over a link, usually given in bits per second: kilobits, megabits or gigabits. Note the lowercase b. Bits are not bytes, and a byte is eight bits, so a rate in megabits per second is roughly one eighth of the same number in megabytes per second.
A hypothetical example: on a link rated at 100 megabits per second, a 100 megabyte file is 800 megabits. At the full rate, that would take about 8 seconds (800 divided by 100). Real transfers usually take somewhat longer because of overhead, competing traffic and limits at the other end.
Bandwidth is shared. If several people stream video and sync large folders at once, each gets a slice. Rated speeds are also theoretical ceilings. What you actually get depends on the slowest point between you and the destination, which may be your Wi-Fi, your provider or the remote server.
Latency: how long
Latency is the delay between sending something and seeing the effect. It is typically measured in milliseconds, and the common measure is round-trip time: how long a small message takes to travel to a destination and for the reply to come back. The familiar ping tool reports this.
Several things add up to latency:
- physical distance, since signals travel at finite speed
- the number of devices the data passes through
- queuing, when a device is busy and packets wait their turn
- processing time at the far end
Low latency matters most when the conversation goes back and forth: video calls, remote desktops, online games and loading web pages that need many small requests. Downloading one large file cares much more about bandwidth than latency.
A related term is jitter, which is the variation in latency from one packet to the next. Steady 40 ms is easier to work with than something that bounces between 10 and 200 ms.
Packet loss: how much goes missing
Data is split into packets. Sometimes a packet is dropped, because a link is congested, a wireless signal is weak or a device is overloaded. Packet loss is the share of packets that do not arrive, expressed as a percentage.
What happens next depends on the traffic. Most file transfers and web requests use a protocol that notices missing packets and asks for them again. The data eventually arrives complete, but retransmissions slow things down. Live voice and video often cannot wait, so lost packets show up as choppy audio, frozen frames or robotic voices.
Even small percentages can matter. A well-functioning wired network typically shows little or no loss, so persistent loss is usually a clue that something is wrong, such as a faulty cable, a duff port or interference on a wireless link.
How the three interact
They are related but not interchangeable.
- A satellite-style link can have decent bandwidth but high latency, so downloads are fine and interactive tasks feel sluggish.
- A congested office link might have low latency when idle and high latency when busy, because packets queue up. This effect is sometimes called bufferbloat.
- Heavy packet loss lowers the effective throughput even when the rated bandwidth is large, because the sender keeps backing off and resending.
This is why speed tests that report only one number can mislead. A strong download figure says nothing about whether a video call will be smooth.
Measuring them
Simple tools go a long way:
- Ping shows round-trip time and whether replies are missing. Running it for a minute or two reveals variation.
- Traceroute lists the hops along the path with times for each, which helps locate where delay appears.
- Speed tests estimate throughput to a test server. Results vary by time of day and by server, so repeating them is wise.
- Router and switch statistics often show error and drop counters per port.
Comparing a wired test with a wireless one from the same spot quickly shows whether Wi-Fi is the weak point. The command line basics of ping and traceroute are worth learning because they work on almost any system.
Interpreting what you see
There are no universal thresholds, and what counts as acceptable depends on the task. As rough orientation, local wired traffic usually has very low round-trip times, traffic across the internet to a nearby region is higher, and intercontinental paths are higher still. Treat any single reading cautiously, and look for patterns: always high, high only in the evening, or spiking at random.
Why it matters at work
Complaints about “slow internet” rarely say which of the three is at fault, so asking the right follow-up question saves time: is it slow to load, slow to respond, or does it cut out? The answers point toward a bandwidth limit, latency or loss respectively. Capturing these readings over time through system monitoring helps support conversations with providers and feeds into service level agreements, where connection quality may be promised in measurable terms. For a systematic way to track a problem down, see network troubleshooting.