Bandwidth and Throughput Calculator

Bandwidth vs. throughput

Bandwidth is the raw capacity of a link — the maximum number of bits per second the physical medium can carry. Throughput is the actual data rate delivered to the application after all protocol overhead, retransmissions, and congestion losses are accounted for.

Throughput is always less than bandwidth. The gap depends on the protocol stack, link utilisation, latency, and packet loss rate.

Protocol overhead explained

Every layer of the protocol stack adds headers:

• Ethernet II: 14-byte header + 4-byte FCS = 18 bytes per frame. For a 1500-byte MTU, that is 18/1518 ≈ 1.2% overhead.
• IP + TCP: 20-byte IP header + 20-byte TCP header = 40 bytes of overhead per segment (more with TCP options). On a 1460-byte TCP payload, that is 40/1500 ≈ 2.7%.
• TLS 1.3: adds per-record overhead of 5-byte header + 1-byte content type + 16-byte AEAD authentication tag = 22 bytes. Combined with TCP/IP, total overhead is roughly 4–5%.
• IPsec ESP tunnel mode: adds ESP header (8 bytes), IV (16 bytes for AES-GCM), ICV (16 bytes), and a new outer IP header (20 bytes) = approximately 60 bytes per packet. For small packets this overhead is significant; for 1500-byte frames it is roughly 4–6%, but CPU encryption cost may be the real bottleneck.
• GRE tunnel: adds a 4-byte GRE header and 20-byte outer IP header = 24 bytes per packet, roughly 1.6% overhead at 1500-byte MTU.

Goodput and application-layer throughput

Goodput is the useful payload throughput seen by the application — bandwidth minus protocol overhead, minus retransmissions, minus TCP slow-start ramp-up time. For long-lived TCP flows on a low-loss path, goodput typically reaches 90–95% of the raw link speed. For short flows (less than one RTT), TCP never exits slow start and goodput may be far below the link capacity.

Common link speeds reference

Transfer time calculation

Transfer time = file size in bits / effective throughput in bps.

Note: file sizes are typically measured in bytes (1 byte = 8 bits), and storage vendors use SI prefixes (1 GB = 10⁹ bytes) while operating systems may use binary prefixes (1 GiB = 2³⁰ bytes). This calculator uses SI (1 GB = 1,000,000,000 bytes) for consistency with network speed measurements.

Understanding network bandwidth vs throughput — a deeper look

The distinction between bandwidth and throughput is one of the most misunderstood concepts in networking, and the confusion causes real problems when engineers size WAN links or troubleshoot slow application performance. Bandwidth is a physical property of the link — the maximum bit rate the medium can carry, determined by hardware and signaling standard. A GigabitEthernet interface has 1 Gbps of bandwidth. This number does not change regardless of what is running on the link. Throughput, by contrast, is a measurement of actual data delivery — what the application actually receives per second. Throughput is always lower than bandwidth and varies continuously with network conditions.

The gap between bandwidth and throughput has multiple contributors. Protocol overhead (Ethernet frames, IP headers, TCP headers, TLS records) consumes some fraction of every bit transmitted — typically 3–8% for HTTPS traffic. TCP's congestion control algorithm starts every new connection slowly (slow start) and ramps up over multiple round trips, meaning short-lived connections never approach the link's bandwidth. Packet loss causes TCP to halve its sending rate (congestion avoidance) — even 0.1% packet loss can reduce throughput on a high-bandwidth, high-latency path to a fraction of the link speed. QoS policies, traffic shaping, and policers may impose hard rate limits below the physical bandwidth. Finally, CPU-intensive operations like IPsec encryption can bottleneck throughput well below the wire speed even on a perfectly uncongested link.

Bandwidth planning for enterprise networks

Bandwidth planning requires estimating peak concurrent demand across all traffic classes, not average utilisation. Networks are sized for the 95th-percentile traffic load — the bandwidth level exceeded only 5% of the time during business hours. A link running at 80% average utilisation sounds acceptable, but if it spikes to 100% for even a few seconds during backup windows or video calls, packets will queue, latency spikes, and voice quality degrades. Most enterprises target no more than 70% sustained utilisation on WAN links to leave headroom for bursts.

Traffic profiling is the foundation of bandwidth planning. Before sizing a link, identify the major traffic categories: user internet traffic, intra-office application traffic, voice and video conferencing, backup jobs, software updates, and management traffic. Each has different characteristics: voice needs low latency and consistent bandwidth (G.711 codec uses 64 Kbps per call, G.729 uses 8 Kbps); backup jobs create large sustained bursts that must not starve other traffic; video conferencing uses 1–4 Mbps per HD stream but is extremely sensitive to jitter. Use QoS policies to classify and prioritize traffic so that a backup job cannot consume all available bandwidth during business hours.

For WAN link sizing, collect NetFlow or SNMP traffic data from existing links if available. If sizing a new site, estimate per-user bandwidth by traffic type: 500 Kbps per concurrent user for general web browsing, 2–4 Mbps per active video conference session, plus headroom for cloud application traffic. Add 20% growth buffer and round up to the nearest available service tier. Remember that most WAN services are asymmetric — downstream bandwidth exceeds upstream — so verify that the upstream capacity supports video conferencing and cloud uploads, not just the downstream speed.