Network Performance - Learning Module

Loading content...

0/228

Throughput

What Actually Flows Through the Pipe

If bandwidth is the width of the highway, throughput is how many cars actually reach their destination per hour. Your internet connection might boast 100 Mbps of bandwidth, but the file download showing 8 MB/s tells the real story of throughput.

Throughput is the actual rate of successful data delivery through a network, measured over a given time period. It's the practical measure of network performance that users experience and applications depend upon—not what the network could do in theory, but what it does do in reality.

What You Will Learn

By the end of this page, you will understand throughput as the practical counterpart to bandwidth. You'll learn why throughput always falls below bandwidth, how to identify bottlenecks, measure real performance, and apply optimization strategies that maximize useful data transfer.

Defining Throughput: The Real-World Metric

Throughput measures what networks actually deliver—not their theoretical potential, but their measured output. Several related terms are used in the industry, often interchangeably but with subtle distinctions:

Throughput: The rate at which data successfully traverses the network from source to destination, including all overhead.

Goodput: The rate of useful data delivery, excluding protocol overhead like headers and retransmissions. Goodput ≤ Throughput.

Effective Bandwidth: Another term for achieved throughput, emphasizing it's the 'effective' portion of raw bandwidth.

Transfer Rate: User-focused term typically meaning goodput as seen by the application.

Throughput-Related Terms Compared
Term	Measures	Includes Overhead?	Typical Context
Bandwidth	Maximum capacity	N/A (theoretical)	Link specifications
Throughput	Actual data rate	Yes (all bits on wire)	Network engineering
Goodput	Useful data rate	No (application data only)	Application performance
Transfer Rate	User-visible speed	No (file bytes)	End-user experience

The Hierarchy of Data Rates

In practice: Bandwidth ≥ Throughput ≥ Goodput. Understanding this hierarchy helps you diagnose where performance is lost. If throughput is close to bandwidth but goodput is low, the issue is overhead. If throughput itself is low, look at network conditions.

Time Matters:

Throughput is inherently time-dependent. The same network can show vastly different throughput depending on when you measure:

Instantaneous throughput: Speed at a single moment (noisy, highly variable)
Short-term average: Over seconds to minutes (useful for active monitoring)
Long-term average: Over hours to days (capacity planning, SLA compliance)

For meaningful analysis, always specify the measurement interval and understand that throughput fluctuates naturally.

Why Throughput is Always Less Than Bandwidth

The gap between bandwidth and throughput isn't a bug—it's fundamental to how networks work. Multiple mechanisms consume capacity without contributing to user data transfer:

1. Protocol Overhead: Every layer of the network stack adds headers, trailers, and control information:

Protocol Overhead Analysis (1500-byte Ethernet frame)
Layer	Headers/Overhead	Bytes	% of Payload
Ethernet	Preamble, MAC addresses, FCS	38	2.5%
IP	IP header (v4)	20	1.3%
TCP	TCP header (no options)	20	1.3%
TCP Options	Timestamps, SACK, etc.	0-40	0-2.7%
TLS	Record header + MAC + padding	25-50	1.7-3.3%
Total		103-168	6.8-11.2%

With typical overhead, even a perfectly functioning network delivers only ~90-93% of bandwidth as goodput. Small packets suffer even more—a 64-byte packet carrying 6 bytes of useful data has 90%+ overhead.

2. Control Traffic: Networks require non-data traffic to function:

TCP acknowledgments (pure overhead when asymmetric)
Routing protocol updates (BGP, OSPF, etc.)
ARP/NDP for address resolution
DHCP, DNS, NTP, and other infrastructure
Keepalives and heartbeats

3. Retransmissions: Packet loss requires re-sending data, wasting bandwidth:

A single lost packet in TCP triggers retransmission
Timeout-based retransmissions waste RTT × Bandwidth
Severe loss causes exponential congestion backoff

The Packet Loss Multiplier

Packet loss has nonlinear effects on TCP throughput. At 0.1% loss, throughput might be 80-90% of capacity. At 1% loss, it can drop to 30-50%. At 5% loss, throughput may be 10% or less of bandwidth. On high-latency links, these effects are even more severe.

4. Congestion and Queuing: When traffic exceeds capacity, queues form:

Queue delays add latency
Queue overflow causes packet loss
Active Queue Management (AQM) may drop packets preemptively
Congestion collapses throughput across all competing flows

5. Flow Control Constraints:

TCP window limits data in flight
Receiver advertised window may be smaller than BDP
Application may not read fast enough, closing the window

6. Physical/Link Layer Issues:

Wireless contention and collisions
Signal degradation requiring lower modulation
Half-duplex mode on shared media
Error correction consuming capacity

Comprehensive Factors Affecting Throughput

Throughput is influenced by factors spanning every layer of the network and beyond. Understanding these factors is essential for diagnosis and optimization.

Network Factors:

Network-Level Throughput Factors

•Bottleneck Link Bandwidth — Throughput cannot exceed the slowest link in the path. A 1 Gbps connection through a 100 Mbps link maxes at 100 Mbps.
•Round-Trip Time (RTT) — Higher latency reduces throughput in window-based protocols like TCP. Throughput ≈ Window_Size / RTT.
•Packet Loss Rate — Loss triggers retransmissions and congestion control backoff, severely degrading throughput.
•Congestion Level — Competing traffic shares bandwidth; more flows mean less per-flow throughput.
•Path Length and Hops — Each hop adds processing delay and potential for loss or congestion.
•Network Jitter — Variation in delay causes out-of-order packets, triggering spurious retransmissions in TCP.

End-System Factors:

End-System Throughput Factors

•CPU Processing Capacity — The CPU must process each packet; high-speed networks can be CPU-bound.
•Memory and Buffer Size — Insufficient memory limits TCP window size and causes socket buffer overflow.
•Storage I/O Speed — Disk speed can bottleneck file transfers; a 100 Mbps HDD can't sustain 1 Gbps throughput.
•NIC Capabilities — Older NICs, drivers, or missing offload features limit achievable throughput.
•Operating System Tuning — Default socket buffers, TCP parameters, and interrupt handling affect throughput.
•Application Design — Poor algorithms, single-threaded I/O, or blocking operations limit throughput.

Protocol Factors:

Protocol-Level Throughput Factors

•Congestion Control Algorithm — Reno, CUBIC, BBR, etc. each respond differently to loss and delay.
•TCP Window Size — Must match or exceed BDP for full utilization; window scaling required for high-BDP paths.
•Slow Start Behavior — New connections ramp up slowly, taking time to reach full throughput.
•Nagle's Algorithm — Can introduce delays for small writes; may need TCP_NODELAY for latency-sensitive apps.
•Delayed ACKs — 40-200ms ACK delays can reduce throughput, especially with small windows.
•Encryption Overhead — TLS handshakes add RTTs; encryption/decryption consumes CPU cycles.

Sender-Limited vs. Network-Limited

Throughput issues are either sender-limited (end-system can't generate packets fast enough) or network-limited (network can't deliver packets fast enough). Diagnosing which is critical: fixing the wrong end wastes effort.

Throughput is End-to-End

Unlike bandwidth (per-link property), throughput is measured end-to-end. A chain is only as strong as its weakest link, and throughput reflects the entire path including endpoints.

Throughput and TCP: A Deep Dive

TCP dominates Internet traffic, and understanding its throughput characteristics is essential for network performance analysis.

TCP Throughput Equation:

The simplified Mathis equation models TCP throughput:

Throughput ≈ (MSS × C) / (RTT × √p)

Where:

MSS = Maximum Segment Size (typically ~1460 bytes)
C = Constant (~1.22 for standard TCP)
RTT = Round-Trip Time
p = Packet loss probability

This equation reveals crucial insights:

Throughput is inversely proportional to RTT — Double the latency, halve the throughput
Throughput drops with √loss — Even small loss rates cause significant degradation
Larger MSS helps — Jumbo frames improve efficiency on high-speed paths

tcp_throughput_model.py
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
import math
 
def mathis_throughput(mss_bytes: int, rtt_ms: float, loss_rate: float, 
                      c: float = 1.22) -> float:
    """
    Calculate theoretical TCP throughput using Mathis equation.
    
    Args:
        mss_bytes: Maximum Segment Size in bytes
        rtt_ms: Round-Trip Time in milliseconds
        loss_rate: Packet loss probability (0.0 to 1.0)
        c: Constant (~1.22 for standard TCP)
    
    Returns:
        Throughput in bits per second
    """
    if loss_rate <= 0:
        # No loss - limited by bandwidth or window, not this model
        return float('inf')
    
    rtt_seconds = rtt_ms / 1000
    mss_bits = mss_bytes * 8
    
    throughput_bps = (mss_bits * c) / (rtt_seconds * math.sqrt(loss_rate))
    return throughput_bps
 
def format_throughput(bps: float) -> str:
    """Format throughput in human-readable form."""
    if bps == float('inf'):
        return "Unlimited (bandwidth-limited)"
    for unit, divisor in [("Gbps", 1e9), ("Mbps", 1e6), ("Kbps", 1e3)]:
        if bps >= divisor:
            return f"{bps/divisor:.2f} {unit}"
    return f"{bps:.2f} bps"
 
# Demonstrate impact of RTT and loss
print("=== TCP Throughput Analysis (Mathis Model) ===\n")
print("MSS = 1460 bytes\n")
 
# Varying RTT with 0.1% loss
print("Effect of RTT (0.1% loss):")
for rtt in [10, 50, 100, 200, 500]:
    tp = mathis_throughput(1460, rtt, 0.001)
    print(f"  RTT {rtt:3d}ms: {format_throughput(tp)}")
 
print()
 
# Varying loss with 50ms RTT
print("Effect of Loss Rate (50ms RTT):")
for loss in [0.0001, 0.001, 0.01, 0.05, 0.1]:
    tp = mathis_throughput(1460, 50, loss)
    print(f"  Loss {loss*100:.2f}%: {format_throughput(tp)}")
 
print()
 
# Real-world scenarios
scenarios = [
    ("LAN (low latency, no loss)", 1, 0.0001),
    ("Metro (moderate latency)", 20, 0.001),
    ("Transoceanic (high latency)", 150, 0.002),
    ("Congested WiFi", 30, 0.03),
    ("Cellular (poor signal)", 100, 0.05),
]
 
print("Real-World Scenarios:")
for name, rtt, loss in scenarios:
    tp = mathis_throughput(1460, rtt, loss)
    print(f"  {name}")
    print(f"    RTT={rtt}ms, Loss={loss*100:.2f}%")
    print(f"    Max Throughput: {format_throughput(tp)}\n")

The Latency-Loss Double Penalty

High-latency, lossy links suffer doubly: retransmissions waste more time (RTT for recovery), and the throughput equation compounds both factors. A 200ms RTT with 1% loss yields theoretical max of ~4 Mbps—regardless of link bandwidth.

Congestion Control Evolution:

TCP congestion control has evolved significantly, each generation improving throughput in specific scenarios:

TCP Tahoe/Reno (1988-1990): Loss-based, AIMD (Additive Increase, Multiplicative Decrease). Simple but aggressive.
TCP NewReno (1999): Better Fast Recovery, handles multiple losses per window.
TCP CUBIC (2006): Current Linux default. Scales better on high-BDP paths.
TCP BBR (2016): Google's approach. Models bandwidth and RTT directly, not loss. Better throughput on lossy paths.
TCP BBRv2/v3 (2020+): Improved fairness and coexistence with loss-based algorithms.

Choosing the right congestion control can dramatically affect throughput, especially on challenging paths.

Measuring Throughput Accurately

Accurate throughput measurement requires careful methodology. Poorly designed tests often blame the network for application or endpoint issues.

Measurement Principles:

Measure at the right layer — Application throughput ≠ network throughput. Decide what you're measuring.
Control variables — Isolate what you're testing. One variable at a time.
Sufficient duration — Short tests miss TCP ramp-up and variability. Use 10+ seconds.
Multiple samples — Network performance varies. Report percentiles, not just averages.
Understand your tools — Each tool has limitations and biases.

Throughput Measurement Tools and Methods
Tool/Method	Measures	Strengths	Limitations
iperf3 (TCP)	End-to-end TCP throughput	Configurable, reliable	Requires server on far end
iperf3 (UDP)	Raw network capacity	No TCP limitations	Doesn't reflect real TCP performance
Speedtest.net	Throughput to test servers	Easy, no setup	Server selection, marketing-optimized
wget/curl timing	Application-layer transfer	Real-world test	Server/storage bottlenecks
tcptraceroute + perf	Per-hop analysis	Identifies bottlenecks	Complex, requires expertise
SNMP/NetFlow	Interface utilization	Non-intrusive, continuous	Device-side view only

throughput_measurement.py
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
#!/usr/bin/env python3
"""
Throughput measurement and analysis utilities.
Demonstrates proper measurement methodology.
"""
 
import socket
import time
import statistics
from typing import List, Tuple
 
def measure_tcp_throughput(host: str, port: int, 
                           duration_seconds: float = 10,
                           buffer_size: int = 65536) -> dict:
    """
    Measure TCP throughput by receiving data from a server.
    
    This implements a simple throughput test receiver.
    The server should be sending continuous data.
    """
    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    sock.setsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF, buffer_size * 4)
    
    try:
        sock.connect((host, port))
        sock.setblocking(True)
        
        total_bytes = 0
        samples = []
        
        start_time = time.perf_counter()
        last_sample_time = start_time
        sample_bytes = 0
        
        while (time.perf_counter() - start_time) < duration_seconds:
            data = sock.recv(buffer_size)
            if not data:
                break
            
            bytes_received = len(data)
            total_bytes += bytes_received
            sample_bytes += bytes_received
            
            # Take samples every second
            now = time.perf_counter()
            if now - last_sample_time >= 1.0:
                sample_throughput = (sample_bytes * 8) / (now - last_sample_time)
                samples.append(sample_throughput)
                sample_bytes = 0
                last_sample_time = now
        
        elapsed = time.perf_counter() - start_time
        
    finally:
        sock.close()
    
    avg_throughput = (total_bytes * 8) / elapsed if elapsed > 0 else 0
    
    return {
        "total_bytes": total_bytes,
        "duration_seconds": elapsed,
        "average_throughput_bps": avg_throughput,
        "average_throughput_mbps": avg_throughput / 1e6,
        "samples_bps": samples,
        "min_throughput_mbps": min(samples) / 1e6 if samples else 0,
        "max_throughput_mbps": max(samples) / 1e6 if samples else 0,
        "stddev_mbps": statistics.stdev(samples) / 1e6 if len(samples) > 1 else 0,
    }
 
def analyze_throughput_samples(samples_mbps: List[float]) -> dict:
    """
    Analyze throughput samples for reporting.
    
    Reports percentiles which are more meaningful than averages
    for variable network performance.
    """
    if not samples_mbps:
        return {}
    
    sorted_samples = sorted(samples_mbps)
    n = len(sorted_samples)
    
    def percentile(p: float) -> float:
        idx = int(p * n / 100)
        return sorted_samples[min(idx, n-1)]
    
    return {
        "count": n,
        "mean": statistics.mean(samples_mbps),
        "median": statistics.median(samples_mbps),
        "p5": percentile(5),    # Low end
        "p25": percentile(25),  # Q1
        "p75": percentile(75),  # Q3
        "p95": percentile(95),  # High end
        "min": min(samples_mbps),
        "max": max(samples_mbps),
        "stddev": statistics.stdev(samples_mbps) if n > 1 else 0,
        "coefficient_of_variation": (statistics.stdev(samples_mbps) / 
                                      statistics.mean(samples_mbps) * 100
                                      if n > 1 and statistics.mean(samples_mbps) > 0 
                                      else 0),
    }
 
# Example analysis output
example_samples = [95.2, 97.1, 94.8, 92.3, 96.4, 98.1, 93.5, 95.8, 97.3, 94.1,
                   45.2, 89.3, 96.7, 98.2, 95.5]  # Note the outlier at 45.2
 
analysis = analyze_throughput_samples(example_samples)
print("=== Throughput Analysis Example ===")
print(f"Samples: {len(analysis['count'])} measurements")
print(f"Mean:    {analysis['mean']:.1f} Mbps")
print(f"Median:  {analysis['median']:.1f} Mbps")
print(f"P5-P95:  {analysis['p5']:.1f} - {analysis['p95']:.1f} Mbps")
print(f"Std Dev: {analysis['stddev']:.1f} Mbps")
print(f"CV:      {analysis['coefficient_of_variation']:.1f}%")
print("\nNote: Mean (affected by outlier) differs from Median (robust).")

Report Percentiles, Not Just Averages

Throughput varies over time. An average of 100 Mbps could mean consistent 100 Mbps or alternating 50/150 Mbps—very different experiences. Report P5/P50/P95 to capture the distribution. Users experience percentiles; SLAs should reflect them.

Optimizing Throughput: Practical Strategies

Improving throughput requires identifying and addressing bottlenecks systematically. Different bottlenecks require different solutions.

TCP/Socket Tuning:

tcp_tuning.sh
Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
#!/bin/bash
# Linux TCP/network tuning for higher throughput
 
# === Socket Buffer Sizes ===
# Increase default and maximum socket buffer sizes
# Allows larger TCP windows for high-BDP paths
 
# Receive buffers (min, default, max in bytes)
sudo sysctl -w net.core.rmem_max=134217728
sudo sysctl -w net.core.rmem_default=16777216
sudo sysctl -w net.ipv4.tcp_rmem="4096 87380 134217728"
 
# Send buffers (min, default, max in bytes)
sudo sysctl -w net.core.wmem_max=134217728
sudo sysctl -w net.core.wmem_default=16777216
sudo sysctl -w net.ipv4.tcp_wmem="4096 65536 134217728"
 
# === TCP Window Scaling ===
# Required for windows > 65KB
sudo sysctl -w net.ipv4.tcp_window_scaling=1
 
# === Congestion Control ===
# BBR often provides better throughput than CUBIC on lossy paths
sudo sysctl -w net.ipv4.tcp_congestion_control=bbr
 
# === Other Throughput-Related Settings ===
# Enable TCP timestamps (needed for high-speed and long RTT)
sudo sysctl -w net.ipv4.tcp_timestamps=1
 
# Increase max connections in accept queue
sudo sysctl -w net.core.somaxconn=4096
 
# Increase network device backlog
sudo sysctl -w net.core.netdev_max_backlog=5000
 
# Enable TCP selective acknowledgments
sudo sysctl -w net.ipv4.tcp_sack=1
 
# Allow reuse of TIME_WAIT sockets for new connections
sudo sysctl -w net.ipv4.tcp_tw_reuse=1
 
# === NIC Offloading ===
# Enable hardware offloading features for your interface
INTERFACE="eth0"
ethtool -K $INTERFACE gso on gro on tso on
ethtool -G $INTERFACE rx 4096 tx 4096
 
echo "Network tuning applied. Verify with 'sysctl -a | grep tcp'"

Application-Level Optimizations:

Application Throughput Strategies

•Parallel Connections — Open multiple TCP connections to parallelize transfers. Each connection gets its own window. Common in HTTP/1.1 browsers (6-8 connections per domain).
•HTTP/2 Multiplexing — Single connection, multiple streams. Avoids connection overhead but shares one congestion window.
•QUIC/HTTP/3 — UDP-based, avoids head-of-line blocking. Multiple independent streams in one connection.
•Compression — Reduce bytes on wire. Trade CPU for bandwidth. Especially valuable for compressible data.
•Chunked/Streaming Transfers — Start sending before complete. Overlaps processing with transmission.
•CDN/Edge Caching — Move content closer to users. Reduces RTT, improving throughput via Mathis equation.
•Persistent Connections — Reuse connections. Avoid slow-start penalty on new connections.

Network Infrastructure Optimizations:

Infrastructure Improvements

•Upgrade Bottleneck Links — Identify and upgrade the slowest link. 10x bandwidth improvement often costs 2-3x.
•Reduce Latency — Shorter paths, better peering, edge deployment. Each ms of RTT reduction improves throughput.
•Reduce Loss — Fix failing hardware, add capacity, improve QoS. Even 0.1% → 0.01% loss matters.
•Traffic Engineering — Route traffic optimally, avoid congested paths, balance load.
•WAN Optimization — Deduplication, protocol optimization, local acknowledgment for high-latency links.
•QoS/Prioritization — Ensure important traffic gets bandwidth during congestion.

The Optimization Order

Optimize in order of impact: 1) Fix packet loss first, 2) Reduce latency, 3) Increase bandwidth. Throwing bandwidth at a lossy or high-latency path often doesn't help—the Mathis equation shows why RTT and loss dominate.

Continuous Throughput Monitoring

Production networks require continuous monitoring to detect throughput problems before users complain. A comprehensive monitoring strategy includes:

Interface-Level Monitoring: Monitor network interface utilization on routers, switches, and servers:

SNMP polling of interface counters (bytes in/out)
Streaming telemetry for real-time visibility
Alert on utilization thresholds (>80% sustained)
Track historical trends for capacity planning

Flow-Level Analysis: Understand which flows consume bandwidth:

NetFlow/sFlow/IPFIX for traffic analysis
Top talkers identification
Application-level classification
Anomaly detection for unusual patterns

Synthetic Monitoring: Continuously test achievable throughput:

Scheduled iperf tests between key sites
Download tests from internal/external sources
End-to-end application tests

Throughput Monitoring Metrics
Metric	Description	Alert Threshold	Investigation Trigger
Interface Utilization	% of bandwidth in use	80% for 5 minutes	60% average
Throughput Baseline	Normal vs. current throughput	<50% of baseline	<80% of baseline
Top Flow Ratio	% of traffic from top flow	50%	30%
Synthetic Test	Achieved vs. expected throughput	<70% expected	<85% expected
Application Response	Application-specific throughput	Varies by app	Degradation trend

Establish Baselines First

Before setting alerts, establish what 'normal' looks like. A week of baseline data reveals patterns (peak hours, day-of-week variation). Alerting without baselines leads to false positives or missed problems.

Throughput in Different Network Contexts

Throughput characteristics and optimization strategies vary across network environments:

Data Center Networks:

Very high bandwidth (10-400 Gbps per link)
Very low latency (<1ms)
Small BDP, less TCP tuning needed
Challenge: east-west traffic scaling, microbursts
Solutions: ECMP, RDMA, jumbo frames

Enterprise WAN:

Moderate bandwidth (100 Mbps - 10 Gbps)
Moderate to high latency (10-100ms)
Significant BDP, TCP tuning critical
Challenge: multiple sites, VPN overhead, cloud connectivity
Solutions: SD-WAN, WAN optimization, QoS

Internet/Consumer:

Variable bandwidth (10 Mbps - 1 Gbps)
High variability in path characteristics
Last-mile often the bottleneck
Challenge: shared medium (DOCSIS), ISP policies, peering disputes
Solutions: CDNs, multi-CDN, protocol optimization

Throughput Characteristics by Network Type
Environment	Typical Throughput	Main Bottleneck	Key Optimization
Data Center	10-100 Gbps	Server CPU/storage	RDMA, kernel bypass
Enterprise LAN	1-10 Gbps	Access layer	Upgrade, proper design
Enterprise WAN	100 Mbps-1 Gbps	Link bandwidth	SD-WAN, compression
Cloud IaaS	10-100 Gbps (burst)	Instance type limits	Right-size instances
Home Internet	50-500 Mbps	Last-mile connection	Upgrade ISP tier
Mobile/Cellular	10-100 Mbps	Radio conditions	Edge caching, adaptive bitrate

The Cloud Complication

Cloud environments add complexity: throughput may be throttled by instance type, availability zone placement matters, and 'network optimized' instances cost significantly more. Always verify actual throughput matches expectations with cloud workloads.

Summary: Mastering Throughput

Throughput is the practical measure of network performance—what actually gets delivered versus what the network could theoretically provide. Understanding throughput enables you to diagnose performance problems, optimize systems, and set realistic expectations.

Key Takeaways

•Throughput ≤ Bandwidth — Actual delivery is always less than theoretical capacity due to overhead, loss, congestion, and protocol constraints.
•Goodput is what matters — Users care about useful data delivered, not total bits on the wire.
•TCP throughput is predictable — The Mathis equation shows how RTT and loss dominate; adding bandwidth doesn't help if these aren't addressed.
•Measurement requires methodology — Accurate throughput testing needs duration, multiple samples, and proper tool configuration.
•Optimization follows a hierarchy — Fix loss first, then latency, then bandwidth. Tuning TCP windows and congestion control matters.
•Monitor continuously — Throughput varies over time; baselines and trends reveal problems before users complain.
•Context matters — Data center, WAN, and Internet each have different throughput characteristics and optimization strategies.

What's Next:

With bandwidth (capacity) and throughput (reality) understood, we'll explore latency—the time dimension of network performance. Latency affects everything from user experience to TCP throughput, and it's often the difference between 'fast enough' and 'feels slow.'

Page Complete

You now understand throughput as the practical counterpart to bandwidth. You can identify why throughput falls short, measure it accurately, and apply optimizations appropriate to your environment. This knowledge is essential for any performance-focused network engineering.