next up previous contents
Next: Security Up: Performance Issues Previous: Resource usage

Quake II latency

rq2proxy has been tweaked to provide good performance. With one player, you can get negligible packet lag. The author regularly uses the program to artifically bump up his ping to 150, and has observed no problems.

Preliminary experiments suggest that lag increases by c. 5-11ms for each additional player on the same server (players playing on different servers seem to be more independant of each other: increases of lag of more like 2-7ms have been observed). Unfortunately, the only systems I have to test this on are four rather old SGIs, which aren't really ideal (or sufficient in number), so if you're intending to proxy more than 6-8 games through one server, (i) tread carefully, and (ii) please write in and tell me how it went (or better stil, send me 16 PII/400s with 3Dfx cards and 100Base-T ethernet :-)).

The internal structure of the proxy is rather odd because of its need to get packets in and out with low latency. The Quake II server appears to have some kind of priority queue structure for emitting world packets, and the server and client can only proxy in some defined order. Unfortunately, since the server keeps shuffling its priority queue, this results in the nasty pathology that high-priority packets get trapped (or tossed) behind low-priority packets, which not only causes momentary freezing, but also seems to cause the server to do horrible things to its priority queue, resulting in higher average lag for all players. Again, if anyone notices anything odd (or if anyone at id is feeling helpful), please e-mail me.

Notably, Quake II seems to possess no rate adjustment, and no effective discard - it copes extremely badly with out-of-order packets (freezes and the network icon), so extreme measures have to be taken to avoid sending `old' packets (ie. to avoid buffering). rq2proxy tries to avoid this problem by tossing packets at every opportunity.

Please feel free to play around with the source code (specifically, config.h.in contains a lot of useful #defines: remember to re-run configure after changing it), but note that an awful lot of apparently `good' changes (like extra buffering) will simply result in a few seconds' play, until the packet stream gets segmented into `back-packets' which consistently get stacked behind `forward-packets', the client becomes terminally confused at receiving what are effectively alternate, interleaved histories, displays the network icon and crashes.

The distribution for version 1 of the proxy, which only supported proxying one client to one server, is provided in the version1 directory: it's not very pretty, but may be easier to play with, since it doesn't have any of the complexities of dynamic route allocation or queued packet buffers to worry about.


next up previous contents
Next: Security Up: Performance Issues Previous: Resource usage
Richard Watts
1998-12-22