Why do we set sv_maxrate to 10.000 in our servers? It has anything to do with qw physics? Player's ping? The amount of bandwidth used? Shaft behavior? Or it's one of the god's commandments?

thx!

Who knows why you do it, but I haven't seen such server in 7 years. Starting from 2000-2001 I've seen rates differs from 15000 (peliportti/edome) to 100000 (clan-z.org) in finland.

In KTX configs it defaults to 30000. The server pack I made for mvdsv+ktx has it set to 50000.

The problem with low rate like 10000 is that it is not enough for 77fps. Turn on netgraph and see how frame updates are being disregarded (means your ping increases) as action comes and goes.

But what is the a maximum bandwidth usage for a player on qw? We have the maximum of 64 viewable entities for each player, but I can't figure out the size of the packets to calculate the highest data transfer possible.

rate limits bandwidth in bytes/second, in a duel you probably cant exceed 10000, but in 4on4 its not enough. You can measure with x-netstat http://www.freshsoftware.com/xns/pro/ or qizmo

So, if I have a 1.5KB per packet in a 77fps server, does it means I'll be able to send 1.5KB for each frame? (115.5KB/s)

depending on the mod, in extreme cases, you could see as much as 111kb per player at 77fps. But that's an extreme case.
in reality, the 64 viewable entities are items waiting to be picked up, and consume no bandwidth for the majority of packets (depends how fast/much the player moves, but even then its not all that much).

Use the cl_shownet command. If its set to 1, it'll show you how much data is in each packet. Add 8 to that (sequence, no qport for server->client). Multiply that by the allowed packet rate. You have the bandwidth used.

You could set sv_maxrate to something slightly higher than that. But then when it does reach the new maxrate, you'll notice spikes on the netgraph again... so what's the point in setting maxrate like that? You could set it really high... But the average connection will never reach that. All you'll do is make clients connect slightly slower (or at least prevent mods from spamming aliases) .

You should probably set it to what the server's connection allows, divided by the max expected players. Probably the flaw with maxrate is that its per-player, not per-server. Mneh, your server, your settings.

I'll try to measure how much bandwidth is used by a player on a KTX server in modes 1on1 and 4on4.

Ridiclously funny way for doing that is that you can always shoot nails (nailgun, not sng) in amphi from corner to another with few friends connecting through qizmo. I'm sure you'll reach something like 27000cps (or bytes per second) this way and it's a good indicator of really high rate value that shouldn't be exceeded too easily.

So I'm guessing rate 20000-25000 should be enough, to be safe side use 30000 but these values are kinda high. Well, have it at 50k and it's more than enough, besides servers these days have the power to push those transfer rates multiplied by 500 or so depending on the player count.

If you're trying to put a limit that will never be reached, why have a limit in the first place?

Good question. Probably due to very old limitations regarding downloadrate (that can actually be bypassed with setinfo drate) to make clients not be able to flood servers to death. And the last time I checked there was hard limit for rate serverside, like 100000 or so, I wonder if it's still there. Well I'm not interested in checking it anyway since people can already download at 340-350kB/s using pext with their new ezquakes.

I've made some tests last night @ localhost, running mvdsv with the frogbot mod.

I think most of the values are ok, except for the "4on4" match, where the minimum rate became too high!



Edit.: the forum's resize function is f* the picture. Reload it on a new window and you'll be able to read the text and values.

Just for reference, qport is a workaround for broken routers. Its an alternative to the source port and can be used to work out which client sent it when multiple clients are playing from the same ip should the router be one of the broken ones that spontaneously forgets all nat connections every 2 minuites (or if the nat reset for some other reason). It is only sent from client to server. When I mentioned qport earlier (or rather, the lack of it in sv->cl packets) I was stating the additional qw protocol transport layer overhead that is not shown in cl_shownet. cl->sv=10, sv->cl=8.

frogbot is not the ideal test. It generates fake players in a mod-specific way. a mod that uses the bot features of mvdsv's qvm stuff would be a better test, but I don't know of any with proper ai (so that they fire, ya know?).
Also, due to pvs differences, maps will have a large variation in required packet sizes.

You can use the mqwcl/ezquake command r_netstats (show net) to get a feel for how much data a client can use
When I did some tests many years ago I found that the peak is typically around ~25-30k on a busy FFA server. On certain maps (large open atriums with many players fighting) it may possibly go even higher

FFA is where you really need the high maxrate due to the large number of players coupled with dmm3 (more chance of particle weapons being used).
A few months back I noticed that xs4all ffa had come back using the default 10k rate and hence people were lagging all over the place. Flepser has now increased this.

For 4on4 a maxrate of 25000 is likely sufficient except for exceptional circumstances, although as Spike points out there is little point in setting an arbitrary limit that we 'think' will be always be enough.

On a related note, the qizmo authors also implemented a little-known nailhack function to help make nails less bandwidth-hungry. This function was originally a patch to qwsv, but I believe tonik added it to zqwsv (sv_nailhack toggle) so it is probably present in most modern server branches. You can check if it is enabled on a server by connecting via qizmo, typing .nail and shooting a nail.

nailhack is something else. technically the hack disables a hack already in quakeworld, which allows qizmo to compress nails better (instead of having to send them in every single packet). Originally nails were sent in a compressed form anyway, but this form lacked any id information. CSQC is able to easily mimic qizmo's compression of nails/rockets... but only FTE and DP support that.