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)