Server.cfg

[Bino45]

please :/:/:/:/

You're locking the interp at 15ms instead of setting it to 15.2 (or 30.3 if cl_interp_ratio is 2).

The server tries to send 1 tick every 15ms, yet it takes 15.2ms to calculate the next one—it's unplayable...

[Bino45]

Hi,

If you set the tickrate to 66.6667 and lock the client to a cmdrate of 66, you create that "lerp flickering"—essentially a bottleneck on the client side.

This is precisely where the crux of the problem—and the mathematical flaw in this type of configuration—lies:

On one hand, the server enforces a rate of 66.6667 Hz (meaning a period of exactly 15.0 milliseconds per tick).

On the other, you throttle or lock the client to a fixed rate of 66 packets/updates per second (which mathematically corresponds to a period of 15.1515 milliseconds).

This tiny discrepancy of 0.15 ms per tick accumulates invisibly. The client expects to receive packets based on its 15.15 ms interval, but the server is actually pushing them out every 15.0 ms. This constant timing offset desynchronizes the interpolation buffer, causing instability and that incessant orange/yellow lerp flickering.

To completely eliminate this bottleneck and micro-asymmetry, the administrator has two clean solutions:

Allow the client some flexibility: Do not lock `sv_maxupdaterate` and `sv_maxcmdrate` to a strict integer value of 66 if the server is running with decimal precision; instead, allow a range that lets the client align itself naturally.

Properly align the rates: Ensure that the limits imposed on the client match the server's actual processing rate exactly, avoiding the creation of this artificial clock drift.

So, use `sys_ticrate 66`, not 66.667 or anything else

[Karacho]

You're like one of those guys who claims that his 100.000$ turntable sounds better than a 80.000$ turntable.
Do you really want to debatte this stuff forever?
If the 4played servers are so unplayable for you, why does nobody else complain and complain and complain about it?