Foundations Of Networking
Measuring a Network
BANDWIDTH how MUCH data per second the link
JrCodex·8 min read
Jr Codex Computer Networks Notes
Level: Beginner Prerequisites: Chapter 4: Network Types and Topologies Time to complete: ~20 minutes
Table of Contents
- Bandwidth Is Not Speed
- The Four Components of Latency
- Throughput
- The Bandwidth-Delay Product
- Jitter and Packet Loss
- Measuring It Yourself
- Summary & Next Steps
1. Bandwidth Is Not Speed
The Distinction
─────────────────────────────────────────
BANDWIDTH how MUCH data per second the link
can carry. Bits per second.
LATENCY how LONG one bit takes to arrive.
Milliseconds.
These are independent. A satellite link can have
enormous bandwidth and 600ms latency. A direct
fibre can have modest bandwidth and 2ms latency.
─────────────────────────────────────────
The Analogy Worth Keeping
─────────────────────────────────────────
A lorry full of hard drives driven across a
country has ENORMOUS bandwidth — petabytes — and
terrible latency: eight hours.
A phone call has tiny bandwidth and excellent
latency.
"Faster internet" almost always means more
BANDWIDTH, and it does nothing for the latency
that makes a website feel slow.
─────────────────────────────────────────
Which One a User Notices
─────────────────────────────────────────
Loading a web page needs many small round trips
— DNS, TCP handshake, TLS handshake, then the
request (Module 5).
Each round trip costs LATENCY, not bandwidth.
Doubling bandwidth from 50 to 100 Mbps barely
changes page load time. Halving latency from
100ms to 50ms transforms it.
This is why CDNs (Module 7, Chapter 2) exist:
they attack latency by moving content closer, not
by adding bandwidth.
─────────────────────────────────────────
2. The Four Components of Latency
Where the Milliseconds Go
─────────────────────────────────────────
1. PROPAGATION DELAY
Time for the signal to travel the distance.
distance ÷ (~200,000 km/s in fibre)
London to New York ≈ 5,600 km ≈ 28ms one way,
56ms round trip. IRREDUCIBLE — this is physics.
2. TRANSMISSION DELAY
Time to push all the bits onto the wire.
packet size ÷ bandwidth
1500 bytes on 100 Mbps ≈ 0.12ms
3. QUEUING DELAY
Time waiting in a router's buffer behind other
packets.
0ms to seconds. THE MOST VARIABLE COMPONENT.
4. PROCESSING DELAY
Time for a router to examine headers and
decide the next hop.
Microseconds on modern hardware.
─────────────────────────────────────────
def latency_ms(distance_km, packet_bytes, bandwidth_mbps, queue_ms=0):
propagation = distance_km / 200_000 * 1000 # 200,000 km/s in fibre
transmission = (packet_bytes * 8) / (bandwidth_mbps * 1e6) * 1000
return propagation + transmission + queue_ms
print(f"{latency_ms(5600, 1500, 100):.2f} ms") # London→NY: 28.12 ms
print(f"{latency_ms(10, 1500, 100):.3f} ms") # across town: 0.170 msThe Consequence of Component 1
─────────────────────────────────────────
Propagation delay CANNOT be optimised. No
protocol, no hardware, no money changes the speed
of light.
So the only way to reduce it is to REDUCE THE
DISTANCE — put the server nearer the user.
That single fact is the entire business case for
content delivery networks and edge computing.
─────────────────────────────────────────
3. Throughput
Bandwidth vs Throughput
─────────────────────────────────────────
BANDWIDTH the theoretical maximum
THROUGHPUT what you actually achieve
GOODPUT useful application data, excluding
headers and retransmissions
─────────────────────────────────────────
Why Throughput Is Always Lower
─────────────────────────────────────────
PROTOCOL OVERHEAD 58 bytes per frame
(Chapter 3) — about 4% on
full-size frames
THE BOTTLENECK LINK end-to-end throughput is
the MINIMUM bandwidth along
the path. A gigabit
connection through a 10 Mbps
link gives 10 Mbps.
TCP BEHAVIOUR slow start, congestion
control and retransmission
all reduce it (Module 4)
THE OTHER END the server may be slower
than your connection
CONTENTION you are sharing the link
─────────────────────────────────────────
4. The Bandwidth-Delay Product
The most important number in this chapter, and the least known.
The Definition
─────────────────────────────────────────
BDP = bandwidth × round-trip time
It is how much data can be "in flight" on the
link at once — the capacity of the pipe itself.
Think of the network as a physical pipe:
bandwidth is its diameter, latency its length.
BDP is its VOLUME.
─────────────────────────────────────────
def bdp_bytes(bandwidth_mbps, rtt_ms):
return (bandwidth_mbps * 1e6 / 8) * (rtt_ms / 1000)
print(f"{bdp_bytes(100, 10):>12,.0f} bytes") # LAN-ish: 125,000
print(f"{bdp_bytes(1000, 80):>12,.0f} bytes") # transatlantic: 10,000,000
print(f"{bdp_bytes(10, 600):>12,.0f} bytes") # satellite: 750,000WHY IT MATTERS
─────────────────────────────────────────
A sender may only have as much unacknowledged
data outstanding as its WINDOW allows
(Module 4, Chapter 4).
IF THE WINDOW IS SMALLER THAN THE BDP, the sender
transmits, then STOPS and waits for an
acknowledgement — leaving the pipe mostly empty.
Transatlantic 1 Gbps link, 80ms RTT:
BDP = 10 MB
A 64 KB window achieves 64KB / 0.08s ≈ 6.4 Mbps
0.64% of the available bandwidth. The link is
fine. The window is the bottleneck.
This is the LONG FAT NETWORK problem, and it is
why TCP window scaling exists (Module 4,
Chapter 4).
─────────────────────────────────────────
5. Jitter and Packet Loss
JITTER — variation in latency
─────────────────────────────────────────
Packets arriving 20ms, 25ms, 18ms, 60ms, 22ms
apart have jitter even though the average is
fine.
Caused mainly by QUEUING DELAY varying with
congestion.
WHY IT MATTERS: real-time media. Audio must play
at a constant rate, so a jittery stream needs a
JITTER BUFFER — which adds latency deliberately
to smooth it out.
For a file download, jitter is irrelevant. For a
phone call, it is everything.
─────────────────────────────────────────
PACKET LOSS
─────────────────────────────────────────
Causes:
CONGESTION a router's queue is full, so
it drops. THE MOST COMMON.
CORRUPTION a bit flipped; the frame's
checksum fails (Module 2)
ROUTING a transient loop or a TTL
expiry (Module 3)
Effects by protocol:
TCP detects and retransmits, and INTERPRETS
loss as congestion, so it slows down
(Module 4, Chapter 4)
UDP does not notice. The application must
cope, or not care.
─────────────────────────────────────────
The Number That Surprises People
─────────────────────────────────────────
1% packet loss can reduce TCP throughput by more
than half.
Not because 1% of data is lost — because TCP
reads loss as a congestion signal and reduces its
sending rate, then rebuilds slowly.
This is why wifi feels slow long before it looks
broken: a little loss triggers a large throughput
penalty (Module 4, Chapter 5).
─────────────────────────────────────────
6. Measuring It Yourself
# LATENCY and LOSS — the first command for any network problem.
ping -c 20 example.com
# rtt min/avg/max/mdev = 12.1/14.3/38.9/4.2 ms
# └ propagation └ typical └ a queuing spike └ JITTER
# PER-HOP latency: where does it jump?
traceroute example.com # tracert on Windows
mtr example.com # continuous; the best of the three
# BANDWIDTH between two machines you control.
iperf3 -s # on the server
iperf3 -c server.example.com -t 30 # on the client
# WHAT THE APPLICATION EXPERIENCES — the breakdown that matters.
curl -w "dns:%{time_namelookup}s connect:%{time_connect}s \
tls:%{time_appconnect}s ttfb:%{time_starttransfer}s total:%{time_total}s\n" \
-o /dev/null -s https://example.comReading the curl Breakdown
─────────────────────────────────────────
dns high ──► resolver problem
(Module 5, Chapter 1)
connect high ──► propagation delay; the
server is far away
tls high ──► extra round trips in the
handshake (Module 6, Ch.3)
ttfb high ──► the SERVER is slow, not the
network
total >> ttfb ──► bandwidth or a large
response
This single command separates "the network is
slow" from "the server is slow" — which are
investigated completely differently.
─────────────────────────────────────────
7. Summary & Next Steps
Key Takeaways
- Bandwidth and latency are independent; page load time is dominated by round trips, so latency matters far more than bandwidth for perceived speed.
- Propagation delay is set by physics and can only be reduced by reducing distance, which is the entire justification for CDNs and edge computing.
- The bandwidth-delay product is the volume of the pipe; a window smaller than the BDP leaves the link mostly idle regardless of its capacity.
- One percent packet loss can halve TCP throughput, because TCP interprets loss as congestion and reduces its rate rather than merely resending.
Module 1 Complete — What's Next
You have the vocabulary, the layering model, the encapsulation mechanism and the measurements. Module 2 starts at the bottom of the stack: how bits actually cross a wire, and how a frame gets to the right device on a local network.
Concept Check
- Why does doubling your bandwidth barely change how fast a web page feels?
- Compute the BDP for a 1 Gbps link with 80ms RTT, and explain what happens with a 64 KB window.
curlreports low connect time and high time-to-first-byte. Where is the problem?
Next Module
→ Module 2: Physical & Data Link Layers
Jr Codex — 1-on-1 Personalized Coaching | Back to Module Index | Back to Computer Networks Index