Simulating network latency and jitter

[Jay Dolan]

[frag.machine]

What about dropped or just out of order packets ?

[Spike]

one thing to look out for is when the ISP effectively only ever delivers packets in pairs (multiplexing in bursts to different clients in turn can be more efficient at the cost of extra lag).
this of course screws up naive interpolation based upon packet arrival times (vanilla quakeworld packets have no timestamps within them so has no choice, while other protocols still need to deal with stalls and inaccurate clocks).

[Jay Dolan]

[Spike]

quakeworld goes with 72hz by default. there's a few servers that crank it up to 150hz...
but then vanilla quakeworld also had no prediction so dupes were not even noticable, and the server only responds if the client actually sent a packet, which reduces dupes too...

FTE handles it the Q3 way (if you set cl_lerp_smooth 1, anyway). that is, instead of only tracking the two latest snapshots, have a whole series of snapshots, 64 or whatever.
add a serverside timestamp, and you will now know the exact timings instead of depending on arrival time.
then your client's time can run somewhat independantly from the server. just pick the two snapshots with a timestamp each side of your local simulation time.
if you've got a missing packet then you stall your simulation time, otherwise you drift your client's time to try to retain a frame's worth of buffer or so. if you've got antilag and prediction and stuff, noone will really notice.
the result should completely negate normal jitter, as well as help cover up consistent packetloss - hurrah for staying in the past. if you have heavy-but-consistent packetloss you can just drift another frame into the past. obviously nothing will help complete stalls, and trying to deal with packetloss bursts is just kinda futile. but jitter or consistent packetloss induced by misordered packets should be covered up quite nicely.
the catch is that sounds and particles might appear 'before' they ought to. and of course antilag can have its own issues in a similar vein, but that's true even if the client isn't simulating its own past. To be fair, ALL interpolation is a simulation of the past, you're just nudging it a bit further back.

alternatively if you're JUST after a solution to de-bunch packets, just buffer the entire packet if it would be bunched, then parse it the next frame and fake the arrival time slightly so that lerping still happens. its lame but should mostly work.

[Jay Dolan]

That's helpful, thanks. I'll study how Q3 does it for the `cl_lerp_smooth` case.