bps (bits per second)

bps (bits per second, lowercase b) is the standard unit for data transmission rate. Common multiples: kbps (kilobits, 10³), Mbps (megabits, 10⁶), Gbps (gigabits, 10⁹).

Crucial distinction: bps (bits) is not Bps (bytes). 1 byte = 8 bits, so a 100 Mbps internet connection delivers a theoretical maximum of 12.5 MB/s (megabytes per second). The 8× ratio is a routine source of confusion in ISP marketing — “100 megabit” sounds fast but downloads files at “12.5 megabyte” speeds.

Reference rates:

• Dial-up modem (1990s): 56 kbps
• CD audio: 1411 kbps (uncompressed PCM)
• MP3 (high quality): 320 kbps
• Spotify (Premium): 320 kbps Ogg Vorbis
• YouTube 1080p video: ~5 Mbps
• Netflix 4K HDR: ~25 Mbps
• Modern fiber broadband: 1-10 Gbps
• USB 3.2: 20 Gbps
• Thunderbolt 4: 40 Gbps
• Ethernet datacenter backbones: 100-400 Gbps

For data storage, the byte (or kilobyte, megabyte, etc.) is the standard unit. The convention is essentially: rate in bits, capacity in bytes. Almost every product datasheet follows this.

Why ISPs quote bits, not bytes: the convention dates to the era when most data was serial-line text and the bit was the natural unit on the wire. It also has a marketing benefit: “100 Mbps” sounds eight times larger than “12.5 MB/s”, so every consumer-ISP plan is quoted in bits. Storage vendors learned the inverse trick and quote bytes (a 1 TB drive looks larger than “8 Tbit”). Both conventions are technically correct but ensure the bigger-looking number always sits next to the price.

Advertised vs effective bandwidth: a 100 Mbps connection rarely delivers 12.5 MB/s in practice. TCP overhead (~3-5%), TLS handshake costs, HTTP request/response framing, and last-mile congestion together eat 10-30% of the headline rate on a typical website. For a clean speed test like fast.com or speedtest.net, expect to see 85-95% of the advertised rate; for real-world file downloads from a single server in another country, 50-70% is normal. Related: latency, hertz. Reference: ITU-T — Telecommunication data transmission standards.

Worked example: how long to download a 4 GB game

A 4 GB game file on a 100 Mbps connection: convert to bits = 4 × 8 = 32 Gbit = 32,000 Mbit. Theoretical minimum time = 32,000 / 100 = 320 s ≈ 5 min 20 s. Real-world: assume 80% of advertised throughput due to TCP and HTTP overhead, so closer to 6 min 40 s. On a 1 Gbps fiber line the same download takes ~40 s wall-clock; on a saturated 25 Mbps cable shared with a 4K Netflix stream (which consumes ~25 Mbps of the link), the remaining headroom may be less than 1 Mbps and the download stretches past an hour. This is why CDN-edge caches and HTTP/2 multiplexing — both of which raise effective concurrency without raising raw bps — matter more than peak link speed for browsing experience.

When the bit/byte distinction bites in code

Video transcoding presets are quoted in bps (kbps for audio, Mbps for video); storage limits in containers, S3 lifecycle policies, and Lambda memory caps are in bytes. Mixing these has shipped real production bugs: a CDN egress alarm set to “50 MB/s” when the metric was actually 50 Mbps fired 8× too often and got muted, masking a real exfiltration incident in at least one published postmortem. The defensive habit: always include the unit in variable names — video_bitrate_mbps, not video_bitrate. See also kibibyte for the parallel binary-vs-decimal pitfall on the storage side, and IETF’s RFC 1191 on path MTU discovery for why wire-level throughput rarely matches the headline number.