As I understand the blog post, the difficult (and buggy) part is not the addition of latency, but calculating how much latency to add and where to add it. I'm not sure how tc would help much here, and actually don't see anything to indicate they weren't using tc already.

`tc` would give you non-deterministic microbursts that would be hard to quantify as to whether they impacted competitive integrity. This is an incredibly complex problem if they actually care about millisecond level precision in small duty cycles.

Are you saying that Linux's packet delay function is imprecise? Can you link to more information about this?

That's exactly what I'm saying. I'm describing an implementation detail of traffic shaping. In order to traffic shape, you need to buffer packets. And at some point, you flush that buffer. There is a duty cycle (read: loop) by which you decide when to buffer and when to flush, the timing of this duty cycle is arbitrary/configurable. But no matter the duration of that cycle, when the flush occurs, you naturally get microbursts. So on average, you might be able to target a given millisecond goal over time. But in competitive gaming, average network performance doesn't matter if critical win-or-lose moments are lost to latency fluctuations. The microbursts I spoke of can lead to one team winning the input race over the other as a latent effect of the artificial buffering mechanism (namely the flushing).

Now consider on top of the fact that there are more buffers than just the `tc` buffers involved. This leads to non-linear, non-deterministic fluctuations in latency performance when bursting occurs.

tc is purpose-built to shape throughput, not for tuning precision latency.

(for some context: traffic shaping is a big part of what I work on in my day-to-day helping build and run a wireless ISP)

The problem is that you can't just add a fixed amount of latency to hit a goal of 35ms, you need some sort of algorithm that adaptively changes the amount of added latency to account for occasional spikes in network latency (this is a game that takes >30min so those spikes are guaranteed to happen over the course of a game)

Why not? Their system simulates latency between their facilities in two cities. Latency does not change much. Their solution adjusts to realtime latency variance, but they don't show that such realtime adjustment is needed. The article doesn't say whether they even measured latency variance.

And they also don't show that their dynamic adjustments are more fair than a static adjustment. I think it's likely that their system penalizes local players for too long after a short remote latency spike.