Specifications to run a server.

[Smurf 12]

To be fast:

What are the specifications to run a dedicated server for 50+ people, either on Windows or Linux (when released...)?

Searched in the foruns, BISWiki and even asked to Placebo. Couldn´t find an anwser. Or Im really dumb :p

I need this information cause I have 3 companies\clans waiting to see if they can afford to host a server.

Thanks.

[whisper 0]

http://forums.bistudio.com/showthread.php?t=74957&page=5 bottom page, example of running high player # server (see JMan specs)

[SRRViper 10]

50+ server with no lag = no chance :D

Not with the games netcode you will be lucky to get a 30man server to run with no lag.

minimum server specs I would say it Quad 2.44Ghz with 4gig memory but thats just my oppinion.

[Smurf 12]

So.. and 30 ppl server?

Seen the JMan config, thats a "super-high end" for a server, isn´t? (Dunno nothing about servers and stuff).

So far, thanks, but something more specific (or oficial) would be better.

[[kh]jman 49]

We can run 50 just fine as long as we lock the server from time to time - the lag tends to be caused by 'jip' as players connect & disconnect.

Our server runs at around 35-45% load when full - plenty of overhead. We run Firedaemon, a mailserver, Teamspeak, Vent, IIS and several other web services as well.

We can always add another Quad into the 1U if we need to.

Our old server was on ArmA1 and was a AMD single core 3800+ with 1GB of ram on Win 2003 x64; it did us proud for a year and a half with 30 player coop's and 60 player pvp's, it did max out the cpu @ 100% load so there's your minuim spec right there. Run a nice tight server install, keep your server services optimised and make sure your on a good network (100MB).

Edited June 24, 2009 by [KH]Jman

[SRRViper 10]

what arma.cfg you using [KH]Jman? Ive played about with it but every now and again I'm getting a Desync spike that lasts 30-60 seconds other than that like you say 30 player doesnt run to bad but I would have imagined if I ramped our server up to 50 the Desync I'm seeing would get worse

Our server specs are

Windows Server 2003

Intel Q6700

4Gb DDR2 Memory

100Mbit connection

Also running Firedaemon with infinity set to all 4 cores and priority set to above normal

Would be interesting to see what your nic settings are as well as a comparision to see if tweaking those makes much difference.

Edited June 24, 2009 by SRRViper

[Ketamine 10]

Sry to thread hijack and ask noob questions, forgive me :)

Is there a document or guide somewhere on setting up a dedi ARMA2 server somewhere?

Got a spare server i want to test it on.

Thanks :)

[EvilMax 0]

Hi! We have run Arma and Arma2 servers at our clan server

specification - ASUS P5Q-E, Core2Quad Intel 9550 (2.83Mhz), 4GB RAM, Win2003server x64

WAN - 10 Mbit

all working good with 40 players, 50% CPU loaded

if try start 2 servers (public and private) - 70% CPU.....but in this case WAN is think place for us.

I see that performance in Arma2 server is higher :) - less lag, and yellow/red clip in corner....

[[kh]jman 49]

@SRRViper

The desync we see tends to be generated when players connect - jip lag basically, the jip netcode tranferring the mission data, unit postions and other environmental conditions. The desync will get worse the longer the mission has been running since there's more netcode to transfer to the client. I've never really fully understood why the jip process lags all the other players that are sync'd up, perhaps thats part of the netcode that can be looked at again and optimised (devs comment?). Obviously the more players you have on the server the more potential there is for desync jip lag.

From the joining players point of view, they will observe that in circumstances where the mission has been running some considerable time they may find themselves sitting on 'waiting for host' for some considerable time and once in-game still see the 'red chain' (desync'd) for a further 30 seconds or so whilst their client 'catches up'.

As a clan we have a policy whereby we tend to lock the server as soon as we start seeing jip lag and wait for the joining client to sync up before unlocking the server again and allowing more clients to join this prevents a roll on jip lag effect. This is exactly the same policy we ran for ArmA, it's a shame we stilll have to do it for ArmA2 but there you go I blame the netcode.

I was very careful in choosing a good nic card for the server as it was important for the card to support a TCP/IP offload engine so our server's network card does all the work shifting network I/O load away from the cpu's.

The server is co-located in Rapidswitch's new D3 building. The Rapidswitch network has been independently rated by SpeedTest.net as the fastest network in the UK, and third fastest network in the World so I very much doubt we have any issues on that front.

Since we've had the new server we see no warping so thats certainly confirmation that server's under no real stress. The *.ArmaProfile we use contains the following numbers which seem to work well on 100Mbit

MinBandwidth = 15000000;

MaxBandwidth = 100000000;

MaxMsgSend = 1024;

MaxSizeGuaranteed = 1024;

MaxSizeNonguaranteed = 64;

MinErrorToSend = 0.0025;

On our public server we allow VON but not custom faces and sounds since just as in ArmA it causes additional jip lag on client connect.

Watch for players with pings higher than 300 they will lag the server and everyone else on it.

Edited June 25, 2009 by [KH]Jman

[whisper 0]

Well, considering the amount of data to be sent for syncing a JiP client, either the server pass most of its time sending it, in which case the joining time is not too long, but server has less ressource for updates to playing entities (ie, it generates lag) or the server keeps CPU power for normal operations (ie no lag) but has less time to send data for syncing, in which case JiP process takes ages.

What I don't get : they delegated micro-AI management to a dedicated thread on a second processor, making multi-processors a requirement. Why not do the same for such out-of-game management like syncing of JiP players? Delegate the syncing task to another processor, keep your own normal thread running as usual, wouldn't it solve this JiP lag issue?

[[kh]jman 49]

I like the thoery but only a Bi dev could answer that one I think. I guess it comes down to exactly how the engine is programmed and what the sequence of proceedures it actually goes through during jip. Bi improved jip in ArmA 1.16b considerably but it still couldn't cope with custom faces & sounds particularly well. I'm not sure that the same 'update' has been applied to ArmA2, one would hope so but I'm not convinced.

[SRRViper 10]

Jman;1327367']@SRRViper

The desync we see tends to be generated when players connect - jip lag basically' date=' the jip netcode tranferring the mission data, unit postions and other environmental conditions. The desync will get worse the longer the mission has been running since there's more netcode to transfer to the client. I've never really fully understood why the jip process lags all the other players that are sync'd up, perhaps thats part of the netcode that can be looked at again and optimised (devs comment?). Obviously the more players you have on the server the more potential there is for desync jip lag.

From the joining players point of view, they will observe that in circumstances where the mission has been running some considerable time they may find themselves sitting on 'waiting for host' for some considerable time and once in-game still see the 'red chain' (desync'd) for a further 30 seconds or so whilst their client 'catches up'.

As a clan we have a policy whereby we tend to lock the server as soon as we start seeing jip lag and wait for the joining client to sync up before unlocking the server again and allowing more clients to join this prevents a roll on jip lag effect. This is exactly the same policy we ran for ArmA, it's a shame we stilll have to do it for ArmA2 but there you go I blame the netcode.

I was very careful in choosing a good nic card for the server as it was important for the card to support a TCP/IP offload engine so our server's network card does all the work shifting network I/O load away from the cpu's.

The server is co-located in Rapidswitch's new D3 building. The Rapidswitch network has been independently rated by SpeedTest.net as the fastest network in the UK, and third fastest network in the World so I very much doubt we have any issues on that front.

Since we've had the new server we see no warping so thats certainly confirmation that server's under no real stress. The *.ArmaProfile we use contains the following numbers which seem to work well on 100Mbit

MinBandwidth = 15000000;

MaxBandwidth = 100000000;

MaxMsgSend = 1024;

MaxSizeGuaranteed = 1024;

MaxSizeNonguaranteed = 64;

MinErrorToSend = 0.0025;

On our public server we allow VON but not custom faces and sounds since just as in ArmA it causes additional jip lag on client connect.

Watch for players with pings higher than 300 they will lag the server and everyone else on it.[/quote']

Would that be Checksum offload or Large Sum Offload? we are getting good speeds of our isp so not quite sure whats causing it. our server is located in london and this is a speedtest to manchester

Edited June 25, 2009 by SRRViper

[[kh]jman 49]

Our nic configuration is as follows:

Adaptive Inter-Frame Spacing = 1

Coalesce Buffers = 128

Fast Transmit Completion: On

Enable PME: Disabled

Flow Control: Enabled

Jumbo Frames: Disabled

Offload Receive TCP Checksum: On

Enables the adapter to verify the TCP or UDP checksum of incoming packets.

With Offloading enabled, the adapter completes the verification for the operating system. This feature enhances reception performance and reduces CPU utilization.

Offload TCP Segmentation: On

Enables the adapter hardware to segment data into valid Ethernet frames.

With TCP Segmentation enabled, the adapter segments the data into frames. Because the adapter hardware is able to complete data segmentation much faster than operating system software, this feature greatly increases transmission performance. In addition, the adapter consumes fewer CPU resources.

Offload Transmit IP Checksum: On

Enables the adapter to compute the IP checksum of outgoing packets.

With Offloading enabled, the adapter completes the verification for the operating system. This feature enhances IP transmit performance and reduces CPU utilization.

Offload Transmit TCP Checksum: On

Enables the adapter to compute the TCP or UDP checksum of outgoing packets. With Offloading enabled, the adapter completes the verification for the operating system. This feature enhances TCP and UDP transmit performance and reduces CPU utilization.

QoS Packet Tagging: Disabled

Retransmit Inter-Frame Spacing: 6

[Preacher1974 0]

A question re: custom sounds: why do they cause desyncing if they only run client-side?

[Inkompetent 0]

Preacher;1402393']A question re: custom sounds: why do they cause desyncing if they only run client-side?

What kind of custom sounds do you mean? A soundmod, or those custom sounds you make everyone hear by writing something in the chat? If it's the latter it obviously causes desync since it has to transmit data to all other clients.

[walker 0]

Hi all

I have always thought said several times on this forum that a seperate JIP sychronisation sub server/client is the solution to JIP lag. A seperate process running on another core would be good. Idealy on a seperate computer using other bandwidth would be best.

It would not be too hard to create a sub server/client that serves up the mission then the playing process changes, to within 5%; then hands the synched JIP player off to the main server for the last 10 to 5%.

Perhaps it is time for Server Admins to specify it for BIS.

Kind Regards walker

Edited August 12, 2009 by walker

[Halli~SPARTA~ 0]

Very good topic gents.

I may try the lock deal and see what happens....Thanks

[teacup 2]

Well, considering the amount of data to be sent for syncing a JiP client, either the server pass most of its time sending it, in which case the joining time is not too long, but server has less ressource for updates to playing entities (ie, it generates lag) or the server keeps CPU power for normal operations (ie no lag) but has less time to send data for syncing, in which case JiP process takes ages.

Is there a method, or specific settings that would allow you to draw JIP out, to basicly stretch it's impact out, thus making it less dramatic? JIP players waiting for longer seems like a good compromise, to prevent the game from going to desync hell for everyone already playing.

It's a shame JIP is this crippled. The desync penalty and the extra care mission makers have to take to handle it properly - it doesn't quite come across as a marvel of engineering. It's a bit baffling, that you get lag spikes even when players disconnect, and available CPU/RAM/bandwidth is nowhere near being maxed out.