Server System Requirements

There are two types of servers you can create to run Enemy Territory: Listen servers and Dedicated servers. Listen servers allow you to play the game and host it at the same time, while Dedicated servers only host the game. Dedicated servers use fewer resources than Listen servers, and are therefore more stable to play on. Listen servers work well if you’re playing on a LAN.

Comment: Non-dedicated server's arent "proper" servers and should really only be used when, say, messing about with a few friends, or perhaps on informal LANs. As a general comment with regard to system requirements (below), always veer on the side of caution, better to have smaller or fewer servers than problematic or laggy ones. There are plenty of ET servers out there, there is no point adding another mediocre one, go for quality over quantity.

To run a Dedicated server, we [Splashdamage] suggest you have at least:

· Intel® Pentium® IV 1.3ghz processor or equivalent
ET needs about 30 MHz dedicated to the ET process per player slot. Here is a table with suggested server speeds based upon maximum client settings.

• For a 32 player dedicated server, ET will need 1ghz.
  
• For a 16 player dedicated server, ET will need 500mhz.
  
• For an 8 player dedicated server, ET will need 250mhz.

· 128 MB RAM
This assumes no other applications are running in the background. If other server applications are running, you should expect to need more system RAM.

Comment: 128mb will do but is pushing it somewhat, and I'm pretty sure the OS would have to be Linux. The default com_hunkmegs for clients is 56, for servers apparently it is 72 (this may actually be error in the documentation), which is fine for normal servers, and small servers should be able to even go lower - the documentation suggests a value of 32, while suggesting increasing hunkmegs to 128 for servers of >32 players. I wouldn't suggest going below the default for com_hunkmegs, but there's no need to go giving the server a huge helping of RAM either.

Often the first sign of insuffucient hunkmegs is lots of players crash out with 9999 pings during map changes (beware other issues may cause this also), and if the server crashes with the error "ERROR: Hunk_Alloc failed" (or anything suggestive of a reference to "hunkmegs") this definately suggests increasing hunkmegs.

There is a question as to wether it's maybe necessary to increase hunkmegs if running mods or some custom maps, there's little evidence either way, perhaps suggesting probably not, although it is highly unlikely that most servers are using anything under that default of 72 (or 56) anyway. If you have ram going spare you might aswell use it, but dont bother going above 128mb unless you want to run a really big server.

Note there was a line in the RTCW readme.txt stating never to set the total of all *megs setting to greater than 3/4 of system RAM. Not sure if this was just to allow for the OS and background processes, in which case rather odd to suggest 3/4 of total rather than say nmb or whatever. I'm not really sure if com_zonemegs or com_soundmegs apply for a dedicated server, can't see why they would still be allocated.

· Excellent connection to the Internet or LAN.
We strongly recommend T1 connection speed. Servers on Cable or DSL connections should limit their games to only to 2-4 players (depending on upstream).

Comment: sv_maxrate multiplied by sv_maxclients will give you the peak bandwidth you should allow for. Note that would be in bytes while often bandwidth rates etc server hosts will tell you will be in bits (1/8th of a byte). Also remember for server's it is the upstream that matters, 1mb DSL does not mean you have 1mb of bandwith to play with, usually *DSL (and cable) is asynchronous and you will have something like a mere 265k or 128k upstream. Further, a 'proper server' will be almost right on the "internet backbone", while your DSL connection has to travel to your ISP and whatnot, meaning players are going to have slightly higher pings and less reliable connections even if all else was equal.

If you do some rough calculations, sv_maxrate * sv_maxclients etc that adds up to a lot of bandwith per month. It isnt actually quite so bad however, as most obviously your server probably will not be at 100% capacity all of the time - few servers are at capacity even half of the time (roughly 2pm-2am or so). Less obviously perhaps, even when it is full clients usually dont use all their rate allocation all of the time.

Firstly, any low-bandwidth players will probably be giving themselves less rate - ~4KB/s for modem, 7KB/s for single-channel ISDN, for example. Player's get the lower of sv_maxrate and their own 'rate' setting.

Even still, if you have sv_maxrate 25000 and all your players have rate at 25000, your monthly bandwith usage will not be anything like 25KB/s per player. The engine will only use the rate that it needs to so when players are in fairly empty areas with little action, they will use very little rate, regardless of what limit is imposed. The more players on your server, the more data there needs to be sent to each and so players will use more of their rate allocation more of the time. You should always have sv_maxrate * sv_maxclients available in per-second bandwidth however, as usually the occasions when players are using their maxrate, thats because everyone else is onscreen and there's loads of action, so therefore all other players will be too. The game copes much better with sv_maxrate limiting the rate allocation than it does when your actual bandwidth is insufficient to copy with what the server is trying to use of it. In sum, you need to have the connection (particularily upload speed) that can handle the peak requirements, though monthly data transfer will work out at a much lower average transfer rate.

Vague suggestions:

Players	Good sv_maxrate	Great sv_maxrate
Up to 16	13000 is good	Anything over is great
16-20	13000 is OK	start thinking of increasing to say 16000
21-24	16000 is OK	20000
24-32	16000 at least	25000
32+	20000 at least	25000

Of course, it's always "the higher the better" and 25000 is always best if you have the bandwidth (sv_maxrate is engine limited to 25000 so no point increasing). Bear in mind these suggestions are very rough guesstimates and are not based on any sort of technical or scientific analysis - player's perceptions of what they find laggy, acceptable or excellent varies. I also tend to veer on the side of giving plenty of resources for players to have a great game, rather than try to cram as many players in as possible - quality over quantity. If you have the bandwidth available, the terms with your host allow for it, and dont have to pay for bandwidth usage, always set as high as you can. Even if you do pay for monthly transfer, bear in mind increasing sv_maxrate by 25% (for example) is very unlikely to increase the monthly total bandwidth used proportionally: increases in sv_maxrate has an inelastic effect on total bandwidth used.

Misc. Notes