.: INSIDE Q4 - BANDWIDTH USAGE :.

First theory on bandwidth usage with Quake 4


Like many of you, I was awaiting quake 4 quite nervously. I had some expectations, I was hoping for a lot of features, etc. Now that the game is available, I decided, instead of doing the 1567894th review of the game, to quickly go inside the important part - to me - of the game : the impact on our internet connection for multiplayers gaming.

As the game is so fresh to us, it's yet difficult to tweak it to the best. So, this first part of my review is based on the standard, out of the box, settings we'll have to deal with. Anyway, experience shows that those settings, no matter how bad they can be, will last for a long time. So, let's see what we have by default : for a dsl/cable connection, the maxrate variable is set to 16.000. that's an improvement from quake 3, as it was something like half of it by default (can't remember for sure). That's a good point, as with todays connections' speed, we usually play on the net with a 15.000 maxrate setting. But now for the real test : I was using ethereal sniffer (version 0.10.13) to take traces of the network activity in two different server and situation, with basic configuration. The first test was a ffa game with 3 players, low action. The second one was with 10 players, and a lot of action everywhere.

With 3 players : bad news first, the server is updating the clients 15 times per second only. With a standard configuration (set to dsl/cable), I'm only sending 63 paquets per second (pps) as a client. To speak in Q3-style, it's like having sv_fps down to 15 and maxpackets not set to 125 (somewhere between 60 and 120). The frames were, in general around 200 bytes for the server, and 90 bytes for each player. This is very similar to Q3. The peak values were around 250 bytes and 100 bytes, nothing to worry about. So, in bandwidth use, every player is only needing a connection offering at least 25/45kbps (download/upload), while such a server requires only 132/70kbps.

With 10 players : another server, and still 15pps from the server to the client. This is a confirmation that the default setting is lower than Q3. My client is still sending 63pps, of course. Now, for the big change : the size of the frames are way bigger than Q3 ! It seems a lot more of data is sent to the client, and the more the action, the more the amount of data. During my test, for some long period of time the average size of the server's frames was around 500 bytes, with some peak to 700 bytes. I remember Q3 was only sending to the worst 400 bytes of data, and usually it was around 250 bytes. So it almost double between my previous test on Q3 and this one on Q4 (on Q3 it was a 12 players ctf game with a lot of action). And this has an impact on the bandwidth you need. Hopefully, the client sends the same amount of data, it was measured around 110 bytes with a peak at 130 bytes. So, in bandwidth need, the player uses 60/55kbps in general, and can go up to 82/65kbps in my test. Server side, it's, for 10 players, 540/590kbps and up to 635/820kbps. And remember, client will double his upload bandwidth usage as soon as he will set its rate to 125, like we are used to in Q3 (maxp=125). For sure, this is the reason for Raven to decrease the server refresh from 20 to 15 times per second...

It's difficult to take some conclusions on those first traces. More tests need to be made, and some tweaking need to be discovered. But yet, we can regret one big thing : the server is updating every clients only 15 times per second in standard ! So you can be sure the feeling of the game and the precision is low. This setting is definitely the first one to change for any future competition.