Investigate increasing network update rate for smoother, more reactive gameplay

[Calinou]

To improve multiplayer gameplay, we could increase the client send rate to 125 Hz and the server update rate to 100 Hz. This should be easily doable on today's machines and networks.

See https://extra-a.github.io/#bnet for detailed rationale. Quoting for posterity:

By default Sauerbraten client sends around 30 player position packets per second. Server retranslates these packets to other clients with the same rate of 30 packets per second. Time between two received position packets from a server is also know as pj. Such low rates were used back in 90s for modem connection rates and are obsolete nowadays, only causing huge artificial network lags.

So position handing is working this way. The first step is when a client sends position packet with a delay of sender packet rate (33ms), then it takes a sender network delay before a packet reaches the server. Then server packet rate delay that varies from 0ms to 33ms occurs. And then the final receiver network delay takes place.

This results in artificial delays form 33ms up to 66ms. The first problem is that such values are significant compared to networks delays which are about half of a ping value. The second problem is that the delay varies about twice it's minimum value. Client side interpolation and (Sauerbraten uses client side hit detection) will have significant position errors because a time interval between two received position packets can be two times wider than the original one. Furthermore colliding frequencies of server's and client's packet rates are causing delays on a receiver side. When sender's network delay slightly increases, the time interval between two packets will be more than a server packet rate. So that packet may miss a server time slice. This could often happen even on a very good connection. It also could be seen on a lagometer, client pj will jump up to 66ms, twice the server packet delay time.

The sender packet rate of 125 packets per second with even the default server rate could improve position precision. Several client packets are send to a server per time slice, so additional delay will vary from 33ms to 41ms without any slice misses. And for a server with a lower packets delays of 10ms that value will be even much lower from 10ms to 18ms and position interpolation will be made with 100 packet per second (instead of 30).

In conclusion, client 8ms position packet delay and 10-20ms server one will give much better results. It will increase server traffic around 3 times, but that should not be a problem today. Also these changes are fully compatible with the Sauerbraten default client and server.

See also redeclipse/base#982.

[Fohlen]

After discussing this in detail on Discord we agreed that 64 Hz would be a big improvement already. Can you draft a PR to update this @Calinou ?