DEV Community: Daniel Suhett

Why UDP Beats TCP for Interactive Play

Daniel Suhett — Sat, 21 Jun 2025 13:26:05 +0000

Like many developers, I spend a lot of time at my desk, but I wanted more flexibility in where I could play my games. I began using Moonlight and Sunshine to stream my desktop gameplay to my TVs. When I first started, my games ran at 1080 p/60 fps, but I quickly learned how bitrate scales with resolution: a smooth 4K/120 fps stream can exceed 35 Mb/s, which may overwhelm a home network if it isn’t managed carefully. I’m trying to find the sweet spot between image quality and performance.

This experience gave me a fresh perspective on how UDP is important and enables real-time, low-latency communication.

What UDP Is

User Datagram Protocol (UDP) is a Layer-4 protocol that addresses individual processes on a host by using port numbers and provides a simple way to send and receive data.

Header

The UDP header is only 8 bytes long, keeping each datagram lightweight.

Communication

UDP maintains no connection state on either host. There is no setup or teardown phase.

Multiplexing and Demultiplexing

A sender can multiplex data from many applications into separate datagrams. The receiver then demultiplexes each datagram to the correct application by its destination port.

Low Latency

Because UDP has no handshake, no ordering, and no retransmission, it offers minimal latency between sender and receiver—though without delivery guarantees.

Why Latency Matters

In gaming, every frame is part of a live feedback loop. Dropped or late frames can ruin the user experience. For smooth 60 FPS gameplay, a new frame must arrive every 16.66 milliseconds. At 120 FPS, this drops to 8.33 milliseconds. Professional gamers react to visual stimuli in as little as 100–150 milliseconds, so every bit of latency counts.
TCP’s congestion control mechanisms can introduce unacceptable delays for real-time gaming. UDP allows applications to prioritize timeliness over reliability, implement custom pacing algorithms, and use forward error correction or partial redundancy instead of full retransmissions.

Making the Most of UDP

To compensate for inevitable packet loss and jitter, client-side techniques like jitter buffers, frame interpolation, input prediction, and error concealment are used. These tricks help hide imperfections and keep the stream feeling responsive, even when the network isn’t perfect.

Technique	Purpose
Jitter Buffer	Absorbs small arrival-time variations before decoding.
Frame Interpolation	Reconstructs missing motion vectors, hiding dropped frames.
Input Prediction	Locally simulates next state so lost control packets don’t freeze movement.
Error Concealment	Uses the last good macro-blocks or spatial interpolation when part of a frame is corrupted.

Conclusion

UDP Pros

Simple and lightweight: Small headers, less bandwidth, and stateless operation.
Low latency: Perfect for real-time applications like gaming and streaming.
Fast: No handshake means data gets moving right away.

UDP Cons

No guarantees: No acknowledgments, delivery guarantees, or flow control.
Connection-less: Anyone can send data, which can be a security risk (hello, DNS floods!).
No order or congestion control: Packets might arrive out of order or get lost in the shuffle.

UDP isn’t "worse TCP", it’s a specialized tool designed for speed, not reliability. For modern game streaming, that’s exactly what we need to keep our actions and the on-screen world in sync, with sub-100ms glass-to-glass latency.

The Hidden Bias in AI Code Generation

Daniel Suhett — Fri, 13 Jun 2025 14:38:19 +0000

When we interact with developer communities, it’s striking how differently people experience AI. As with everything in life, it ultimately comes down to training: you soon learn about prompts, context, models, and so on. Two factors, however, shape that first impression more than anything else: the language you write in and the codebase you point the model at.

This is about using foundation models for code. I’ll touch on benchmarks, but it’s not a deep dive into machine learning.

Because code generation is essentially “predict the next token” natural and programming languages with sparse training data fare worse. Outcomes deteriorate further when the prompt language and the target language mismatch: for instance, generating F# from a Chinese prompt performs far worse than generating Java from the same prompt, which itself trails behind Java generated from an English prompt.[1]

The fastest route to an AI-ready repo isn’t buying “the best” model or tool. It’s understanding how the model will interact with your resources.

The Training Data Dominance Effect

Large language models have favorites. Their performance mirrors their training, which is heavily skewed toward a handful of paradigms, languages, and patterns mined from public repos predominantly code that is:

Written in English
Imperative in style
Object-oriented
Using Python, JavaScript, or Java

SWE-PolyBench: A multi-language benchmark for repository-level evaluation of coding agents [6]

Step outside and the model penalizes you. Studies show:

Switching the programming language can cut efficiency by over 20% under the same prompt.
Switching the human language rewriting the prompt in Chinese instead of English decrease by at least 13%.

Exploring Multi-Lingual Bias of Large Code Models in Code Generation [1]

The Benefits of Following the Crowd

This bias extends to everyday frameworks and libraries. Agents perform better with mainstream tooling simply because they encounter it more often [1]. A model can emit sharp code for React, Express, or Django. Ask for Ramda, Preact, or F#, and the output while syntactically correct lags far behind a skilled human’s effort [2 3].

Clean Code Isn’t Just for Humans

The quality of the code you already have directly affects AI output. Clear naming and solid docs hand the agent richer context every time it scans your repo.

Compare two function declarations

calculateTotalPrice(items, taxRate)
calc(arr, x)

The first, with explicit intent and nouns, is far easier for a model to reason about.

Documentation and comments

LLMs love comment blocks and it’s no accident. They learned that well-commented code signals quality [4]. I’m no fan of comment clutter either, yet the data are clear: docstrings and meaningful names consistently raise output quality.

Reinforcement of Stereotypes

Uneven training data introduces flavor-of-language “stereotypes.” A model saturated with JavaScript inevitably excels at UI logic; one steeped in Python gravitates to data-science snippets. Typical niches include:

JavaScript: Front-end logic, UI components, Node.js tooling
Python: Data science, scripting, ML notebooks
Java: Enterprise-scale, strongly structured systems

Leveling the Field with RAG

Retrieval-Augmented Generation (RAG) feeds fresh, domain-specific context at query time. For code, that means injecting docs, examples, and best practices you choose regardless of mainstream popularity. Research shows RAG can boost success rates by 13.5%, especially for frameworks released after a model’s training cutoff [2].

RAG isn’t a magic wand. Context windows are finite and expensive; feeding more context shifts the bottleneck from technical to financial.

Conclusion

Model performance varies more than most people discuss, and benchmarking remains contentious. If you’re having a rough ride, remember:

Different models have different language exposure: try another one.
Stay close to market-standard patterns.
Keep your repo clear and well documented so your AI agent can shine.

I’d love to hear your thoughts drop any studies or experiences in the comments!

References

Exploring Multi-Lingual Bias of Large Code Models in Code Generation — https://arxiv.org/abs/2404.19368
CodeRAG-Bench: Can Retrieval Augment Code Generation? — https://arxiv.org/abs/2406.14497
Investigating the Performance of Language Models for Completing Code in Functional Programming Languages: A Haskell Case Study — https://dl.acm.org/doi/pdf/10.1145/3650105.3652289
Impact of AI-Generated Code Tools on Software Readability & Quality — https://arxiv.org/abs/2402.13280
MultiPL-E: A Scalable and Extensible Approach to Benchmarking Neural Code Generation — https://arxiv.org/pdf/2208.08227
SWE-PolyBench: A Multi-Language Benchmark for Repository-Level Evaluation of Coding Agents — https://arxiv.org/pdf/2504.08703

How Google Reinvented TCP for Faster Video Streaming

Daniel Suhett — Tue, 10 Jun 2025 12:50:52 +0000

Discover how Google replaced a 30-year-old internet rule to fix video buffering and change streaming forever with an congestion control algorithm called BBR.

The Story: My Starting Point

The other day, I was completely absorbed in a live stream, watching a gaming tournament unfold. Suddenly, the crystal-clear 1080p feed I was enjoying turned into a blurry, stuttering mess. My internet connection felt fine, and I knew I had plenty of bandwidth. "What gives?" I wondered. Why does this happen so often with livestreams? My curiosity was piqued, and I felt compelled to dig into how these things actually work.

The Core Problem

For decades, the internet has relied on a simple rule for managing traffic, embedded in a protocol called TCP (Transmission Control Protocol). The core problem, as I discovered, is its fundamental assumption: packet loss always means the network is congested. When a server sends you data and a piece (a "packet") gets lost along the way, TCP assumes the pipes are full and immediately slows everything down to avoid making it worse.

This worked fine in the '80s when networks were simple and slow. But today? It's a disaster for streaming. Our modern networks have huge memory buffers in their routers, which can lead to a phenomenon called bufferbloat. Your data gets stuck in a massive queue, and even though there's no real congestion, the latency skyrockets. On top of that, a flaky mobile connection can drop packets for dozens of reasons—none of which are actual congestion. Yet, traditional TCP sees that loss, panics, and throttles your video stream from crystal-clear HD to a pixelated mess. This old rule is the culprit behind a lot of frustrating livestreaming experiences.

Exploring the Solutions

Google's engineers recognized this outdated assumption was killing YouTube's performance. So, they decided to challenge it and created a revolutionary new congestion control algorithm called BBR (Bottleneck Bandwidth and Round-trip time). Instead of reacting blindly to packet loss, BBR proactively models the network to find the perfect sending rate for real-time video.

Step 1: Measure, Don't Guess

BBR operates on a beautifully simple principle: it constantly measures two key things to understand the network's true capacity, rather than just guessing based on packet loss.

BtlBw (Bottleneck Bandwidth): This is the maximum speed the connection can actually handle right now. Think of it as the true width of the pipe.
RTprop (Round-trip Propagation Time): This measures the absolute minimum time it takes for a packet to travel from the server to you and back. It's the inherent delay of the journey itself.

By knowing these two values, BBR can precisely calculate the "Goldilocks" amount of data to send—just enough to keep the pipe full without overfilling it and creating a queue (bufferbloat).

// A simplified look at BBR's core idea:
function calculateOptimalDataInFlight(bottleneckBandwidth, roundTripTime) {
  const optimalData = bottleneckBandwidth * roundTripTime;
  return optimalData;
}

// BBR knows the max speed (BtlBw) and the travel time (RTprop).
// It calculates the exact amount of data needed to fill the "pipe."
// Anything more than this would just create a queue (bufferbloat)
// and increase latency.

This model-based approach means BBR doesn't have to wait for packet loss to happen. It knows the network's capacity and adapts in real-time, preventing those annoying quality drops before they even occur.

Step 2: Probing for More Speed

BBR doesn't just find a good rate and stick with it; it's always gently probing to see if it can go faster. It cycles through a few states, but the most important is ProbeBW, where it systematically sends a little more data to see if the network's capacity has increased.

This is fundamentally different from older algorithms like CUBIC, which would aggressively fill the buffer until packets started dropping. BBR uses a technique called pacing to send data out in a smooth, consistent stream instead of clumpy bursts. The result? When YouTube switched to BBR, they saw throughput increase by up to 25x on some routes and cut latency by 53% globally!

Downsides and Evolution of BBR

While BBR offers significant performance improvements for streaming, it's not a silver bullet. I learned that early versions (BBRv1) had some drawbacks:

Higher Retransmissions: BBR can sometimes cause more packet retransmissions than traditional algorithms, especially in networks with shallow buffers. This happens because it maintains more data in the network to keep the pipe full.
Fairness Issues: In certain shared network environments, BBRv1 could be unfair to other TCP flows using older, loss-based congestion control algorithms, sometimes grabbing a disproportionate share of bandwidth.
CPU Usage: BBR's continuous measurement and probing phases can be more CPU-intensive than simpler algorithms, which is a consideration for high-speed server environments.

Google addressed many of these issues with BBRv2. This updated version improves fairness with other TCP flows, supports ECN (Explicit Congestion Notification) signals to react better to network congestion, and enhances stability on challenging networks like Wi-Fi.

Where BBR Shines: Use Cases

BBR truly shines in scenarios where traditional congestion control struggles, which often includes exactly what we care about for livestreams:

Video Streaming and Real-Time Media: It dramatically reduces latency and bufferbloat, leading to better video quality and fewer buffering events.
Mobile and Wireless Networks: BBR can better handle the variable packet loss and fluctuating conditions common in cellular and Wi-Fi networks.
Long-Haul and Satellite Links: In these scenarios, packet loss is often not due to congestion, so BBR's model-based approach avoids unnecessary throttling.

Final Thoughts: The Takeaway

The journey of BBR is a powerful lesson: always challenge the underlying assumptions of your technology stack. For 30 years, "packet loss equals congestion" was an unquestioned truth in networking. By creating a system based on live measurement rather than a fixed rule, Google's engineers solved a problem that no amount of front-end optimization could ever fix.

It reminds me that the principles of performance—whether it's in networking, databases, or even how our UI renders—are often universal. Building systems that measure and adapt to real-world conditions will almost always outperform systems that operate on outdated heuristics. This fundamental shift is now baked into next-generation protocols like QUIC, which will power the future of the web, making our livestreams smoother and more reliable.

References

[1] https://cloud.google.com/blog/products/networking/tcp-bbr-congestion-control-comes-to-gcp-your-internet-just-got-faster
[2] https://blog.apnic.net/2020/01/10/when-to-use-and-not-use-bbr/
https://www.reddit.com/r/firewalla/comments/12i9l97/any_downsides_to_enabling_bbr_tcp_congestion/
[3] https://www3.cs.stonybrook.edu/~arunab/papers/imc19_bbr.pdf
[4] https://www.thousandeyes.com/blog/path-quality-brr-future-congestion-avoidance
[5] https://news.ycombinator.com/item?id=14298576
[6] https://dl.acm.org/doi/10.1145/3355369.3355579