32 and 60 slot server requirements (+lag discussion)

(JasperP) #1

Hi,

We (me and a few friends) have a 32 slot ET server running on the following dedicated Linux Fedora 3 server:

- Intel Celeron 2.4 GHz
- 256 MB DDR RAM PC2700
- 40 GB HDD 7200 RPM
- 10 mbit

Unfortunately it lags a bit when it’s full. I think it’s the lack of ram :(. But according to http://www.rtcw.jolt.co.uk/content/enemy_territory/server_guide/requirements.html it should be ok :???:.

Now we want to rent a bigger server for a 60 slot ET server. We have found the following:

- AMD Athlon 64 2800+
- 1GB PC3200 RAM
- 120GB SATA Drive
- 10 or 100 mbit
- 64-Bit CentOS (Enterprise Linux) -or- CentOS (Enterprise Linux) -or- FreeBSD 4.1 -or- Fedora Core 2

I think it would be no problem to host 60 slots on this server? And what would be the best OS? I think CentOS normal version?

Now why do most big servers lag when they are full? Is it because:

  • the server is pushing system hardware
  • the bandwidth can’t be handled
  • something else…?

I really would like to hear C & C about it.

Regards,

Jasper

(Gimpsta) #2

When you say 10Mbit or 100Mbit are you implying that your ISP will give you that amount of bandwidth, or are you quoting the speed of the network card ?
10Mbit will give you approx 1Mb/s transfer rate.

As far as I know ET takes approx 30-35Kb/s per client so a 1Mb connection should just about be able to support 32 players.
1Mb = 1000Kb
1000/30 = 33 players

I have rounded down some figures (10Mbit is actually 1.25Mb/s) because in the real world you never get perfect bandwidth.

(JasperP) #3

Thx for your reaction.

The current host is one of the bigger ones and when you look at what people think of it, also one of the better ones. Also If I dowload a file from it from another server(that is in the same city), the speed gets above 8 Mb/s, so the offer was with 10 mbit(on their site), but it seems it is 100 mbit anyway. So that is why I think it must be a memory problem or maybe a proc. problem.

With the host we have an eye on, you can choose between “10 or 100 mbit”.

I also found this (http://www.planetquake.com/rocketland/haqsau/serversetup.shtml) and from all the info I have read, a client will never come near 30/35 Kb/s. Correct me if I’m wrong or read something the wrong way.

(Sauron|EFG) #4

I think you are mixing bits and bytes in an unhealthy way. :wink:

The actual amount of data sent to each client depends on how much action is going on. Some numbers from an old measurement I did (from client’s pov):

22 player ETPro server (sv_maxrate 15000)
Received (average): 5500 bytes/s
Sent (average): 2500 bytes/s*

Received (max): 11000 bytes/s
Sent (max): 5000 bytes/s

On a 60 slot server you probably want to use maximum rate (25000 bytes per second), which translates into ~200 kbps per client or ~12 Mbps for 60 users. The server doesn’t necessarily use this much bandwidth all the time even if it’s full, but it’s still what you need to minimize lag.

My upload rate was about half the download rate (with cl_maxpackets 30), but I don’t know how that scales on a 60 slot server.

(mortis) #5

I have two pieces of advice:

  1. Don’t use a celeron for heavy duty processing. In my opinion, they are pure suckage. Use Athlons or Pentium processors.

  2. A server should really have more than 256MB of RAM. I usually tell Wolfy to use 128-256MB of RAM depending on the server size and OS. What is the com_hunkmegs of your server set to?

–Mortis

(SCDS_reyalP) #6

The upload rate for each client shouldn’t care at all about the number of players on the server, and not much based on what the client is doing. ET sends commands no matter what. Of course, it will depend on each clients cl_maxpackets and frame rate.

sv_maxrate is in bytes/second. The maximum allowed by the engine is 25000. The server will not send more than that to each client. A 64 player server is likely to hit the 25000 limit quite often. So count on needing a full 12megabit.

(MindgamE) #7

Are you running custom maps? I know there are a few out there that lag like hell when playing with so many people.