You Don’t Know Jack about Bandwidth
Many engineers and end users still conflate bandwidth with latency, leading them to “add more servers” or buy faster internet when the real problem is delay, jitter, or bufferbloat. Commenters share concrete failures—from UIs making dozens of round trips over high-latency links to home connections where a single upload or VPN hop ruins video calls—to illustrate how poor queuing, asymmetric upload speeds, and ISP design choices hurt real-time applications. Several practical remedies are highlighted, such as fq_codel/CAKE-based queue management (often via OpenWrt or LibreQoS), better testing tools, and more latency-aware development and network planning, while noting that large ISPs often lack incentives to adopt them.
Misunderstanding performance and “just add more” scaling
- Many comments describe engineers and managers confusing latency with bandwidth/capacity.
- Pattern: when a single user is slow on an otherwise idle system, people still propose adding cores/replicas; this rarely helps and can increase cost or even worsen DB saturation.
- Analogies (e.g., multiple pregnant women for one baby) are used to illustrate non-parallelizable latency-bound work.
Latency, bufferbloat, and queue management
- Several experiences where users blame “slow bandwidth” but the real culprit is latency and bufferbloat, especially under load (downloads, saturated uplink).
- Fair-queuing + AQM (fq_codel, CAKE, LibreQoS, OpenWrt SQM) are praised for dramatically improving latency under load.
- Some note operators misinterpret “drops” from AQM as bad, when controlled dropping is essential feedback.
Application design and real-world networks
- Many anecdotes of chatty apps (old Win32 clients, web apps, database queries) that work locally but collapse over VPN/3G/satellite due to sequential round trips.
- Developers often test on low-latency, high-bandwidth office networks, missing problems that appear on 4G, rural links, or international paths.
- Frontend bloat (large third‑party scripts, tracking, banking sites loading tens of MB) is criticized as latency-insensitive design.
Home networking, tools, and router choices
- Users report good experiences replacing ISP routers with OpenWrt or OpnSense and enabling SQM; sometimes older hardware performs better due to lower latency.
- Recommended tests include Cloudflare’s speed test, Waveform’s bufferbloat test, flent, and other tools that show latency under load, not just throughput.
- Asymmetric cable (high download, low upload) is a major pain for video calls, Docker image pushes, and ML model uploads; some resort to “sneakernet”-style physical transfer.
ISPs, scaling, and economics
- There is skepticism that open-source QoS middleboxes alone will spur ISP adoption: operational complexity and organizational inertia are seen as bigger barriers than hardware cost.
- Some argue large ISPs rely on ASIC routers with huge capacity and rarely use QoS beyond access edges; others counter that smaller ISPs and regions with expensive transit still benefit.
Terminology and physics clarifications
- Disagreement over using “bandwidth” for data rate vs spectral width; some accept contextual meaning.
- Reminders that signals in fiber travel below the speed of light in vacuum and that propagation, path length, and queuing all contribute to latency.