[PSA: Server Admins] How to Optimize your DayZ Server for MAXIMUM Performance.

[Guest]

Hey everyone,

My name is Vaquxine and today I'll be showing all of YOU some awesome tips and tricks I've uncovered over my time of hosting DayZ servers that allow you host more people on less hardware with NO latency. Before I go any further I'd like to note that much of this guide is for DEDICATED servers, and will not work if you do not have access to an admin RDP account.

This guide will be split into three different sections, each targeting different levels of optimization on your machine and server.

• Software optimization
  
• Network optimization
  
• ARMA2 optimization
  

Software Optimization

Windows isn't a very good platform (especially by default) for hosting servers. It has a cap of 2GB (or 4GB on 64bit) RAM allocation per process, and has none of the advanced performance tuning tools that come built in to Linux machines. That being said, there are some small tweaks and 'hacks' you can use to get the most out of your Windows server.

1. Append your ARMA2 server runtime arguments.
   

The default runtime arguements for ARMA2OAserver are not terrible, but there are a few extra parameters you can add to greatly increase speed. Add the following flags to your server start-up line:

• -noCB : Turns off multicore drawing, this will correct many graphical issues and make loading faster and more stable.
  
• -maxMem=2047: This sets the maximum memory (in megabytes) that the server will be allowed to use. By default the server will automatically detect a value between 512MB - 1536MB, we want to make sure it has as much memory available as possible, which is 2047MB; the hard-coded maximum of ARMA2 (anything higher falls back to 2047).
  
• /REALTIME : This is not an ARMA2 option, and should be added at the start of your command line, right after the 'start' command. It will ensure that your server's process priority is set to 'realtime', meaning the machine will always dedicated as many resources as the process demands to your arma server before any other background processes.
  
• -cpuCount=4 : This should always be set to the maximum cores of your processer. In my case, I have an E3-1270v2 which is a quad core, so I set this to 4 so the server can draw power from all cores. If you're running multiple servers, just divide your cores by the amount of instances of ARMA you run. So if I was running two servers, I'd dedicate 2 CPU cores to each.
  
• -exThreads=1 : Although this parameter is considered obsolete if cpuCount is present, by default all file operations go through a dedicated thread. This offloads some processing from the main thread, however it adds some overhead at the same time. This being said, ARMA2 does not inherently support multi-threading for texture or geometry loading server-side, therefore setting exThreads to anything but 0 or 1 will just create overhead on your server for no reason whatsoever.
  

In the end, your command line should look something like this:

start /wait /REALTIME Expansion\beta\arma2oaserver.exe -mod=EXPANSION\beta;EXPANSION\beta\Expansion;EXPANSION;ca;@dayz;@hive -name=cfgdayz -config=cfgdayz\server.cfg -cfg=cfgdayz\arma2.cfg -profiles=cfgdayz -world=Chernarus -cpuCount=4 -exThreads=1 -maxmem=2047 -noCB

Network Optimization

This is probably the biggest thing that there is to optimize; windows networking is TERRIBLE for servers by default, even on Windows 2008 Web edition. Luckily, there are a few nifty tools that will correct a lot of the mistakes for you.

Go ahead and snatch TCPOptimizer for your version of windows: http://www.speedguid.../downloads.php/ this extremely helpful tool will help optimize your dedicated server's network to minimize packet dropping and data loss.

Although ARMA2 does not require TCP connections to run, DayZ does when performing MySQL queries to the @hive, and acts as a major bottleneck for incoming and outgoing connections that need to be processed through it. This results in ridiculous load times into servers and desyncs on logout. Additionally, these TCP optimizations will allow for more accurate ping returns to your clients, and prevent unnecessary kicks for fake "high pings".

Open open up TCPOptimizer on your server machine, and (assuming you have at least 100mbit connection) move the slider at the top all the way over to the right under "100+MBPS". Check the box "Modify All Network Adapters", then choose "Optimal" at the bottom and hit apply changes. Be sure to restart your dedicated machine right after doing this, as some programs revert many of the TCP settings back to their default values which will still be loaded into memory.

There are a few other settings that are not enabled by default with the 'optimal' profile that I feel should be for ARMA2 hosting. You can edit these advanced values after restarting on optimal settings by choosing the "custom" box on the lower right, which will allow you to edit all fields. You should change:

General Settings ->

TCP Window Auto-Tuning should be on 'experimental'.

** If you run a MySQL server on your dedicated machine, this can cause confliction and should be left as its default value.

Advanced Settings ->

NetworkThrottlingIndex should be on 'high: 70'

TCPMaxDataRetransmissions should be 9 or 10.

Network Memory Allocation Size should be on 'optimized: 3'

TcpAskFrequency should be 'enabled'.

TCPNoDelay should be 'enabled'.

* Make sure you apply changes once finished and reboot your dedicated machine once again.

ARMA2 Optimization

Although the most obvious and easily changed settings, these also have some of the greatest impact on your server's performance. Navigate to your cfgdayz folder which contains arma2.cfg and server.cfg. We'll be focusing mostly on the arma2.cfg, with a few optional edits to the server.cfg. I'll go through each item in the config, explain what it's for, and what its value should be. It should also be noted that these values (excluding Bandwidth / MaxPacketSize) are PER CLIENT CONNECTED TO SERVER.

MinBandwidth

Bandwidth the server is guaranteed to have (in bps).

This value helps server to estimate bandwidth available.

Increasing it to too optimistic values can increase lag and CPU load

as too many messages will be sent but discarded. Default: 131072

MaxBandwidth

Bandwidth the server is guaranteed to never have.

This value helps the server to estimate bandwidth available.

Most players normally use 5-13kb when playing in game but will spike up on certain events such as players joining or when downloading content so a standalone dedicated server connected to at least a 10mbit line is recommended for optimal play.

Your MinBandwidth is your base, it's what the server is expecting to use. Contrary to popular belief, you should not just put your network speed in both min/max bandwidth boxes, as this will cause major connection lag. Remember that Min/Max Bandwidth are measured in bits, not bytes.

Your MinBandwidth should be your player slots x 256KB(its), so for example:

75 slots X 256KB = 19200KB(its)

19200KB(its) = 192000000 Bits

MinBandwidth=192000000;

MaxBandwidth=1073741824;

Although it's said that your MaxBandwidth should be slots x 512KB, I think that's bullshit for dedicated machines only running 1 server. I set my max bandwidth to my network speed in bits. (1GBps)

MaxMsgSend

Maximum number of messages that can be sent in one simulation cycle.

Increasing this value can decrease lag on high upload bandwidth servers. Default: 128

For DayZ purposes, I never set this value higher than 92, and never lower than 64. Although it states it will decrease FPS "lag", it will increase desync; which isn't the same thing.

MaxMsgSend=92;

MaxSizeGuaranteed

Maximum size of guaranteed packet in bytes (without headers).

Small messages are packed to larger frames.

Guaranteed messages are used for non-repetitive events like shooting. Default: 512

MaxSizeGuranteed are packets that are static events that are not player controlled at the data level. Bullet shooting only draws from the location of the player's gun, then just applies physics to it. For DayZ, which is quite heavy PvP, I recommend a low value of 128. A lower value means more packets will be sent for events and less will be combined. This way individual bullets are processed as individual bullets vs. the server registering 4 shots from a makarov at once. You can safely go as low as 64 if you really want, but I don't recommend that for larger servers. (45+ players)

MaxSizeGuranteed=128;

MaxSizeNonguranteed

Maximum size of non-guaranteed packet in bytes (without headers).

Non-guaranteed messages are used for repetitive updates like soldier or vehicle position.

Increasing this value may improve bandwidth requirement, but it may increase lag. Default: 256

MaxSizeNonguranteed is the biggest factor for desyncing, because nonguranteed packets are the ones that are effected heavily by player interaction with the game; such as movement and unit placement. As a rule of thumb, this value should always be about half of the MaxSizeGuranteed value. It should also never be lower than 32, or you'll have desync issues due to multiple packets needing to be sent for simple events.

MaxSizeNonguaranteed=64;

MinErrorToSendNear

Minimal error to send updates across network for near units.

Using larger value can reduce traffic sent for near units. Used to control client to server traffic as well.

MinErrorToSend / MinErrorToSendNear will only effect FPS and smoothness of movement. MinErrorToSendNear determines how smoothly units will move near the player, if for example they are scoped into a sniper rifle since the game needs to compensate for the much larger field of view. The default value is a little ridiculous, and you can easily up it to around 0.05 without noticing any differences in-game since DayZ is limited to a 1.6KM view distance. (ARMA2 goes up to 15KM) That being said, I like to keep things as smooth as possible.

MinErrorToSendNear=0.029999997;

MinErrorToSend

Minimal error to send updates across network.

Using a smaller value can make units observed by binoculars or sniper rifle to move smoother.

Default: 0.01

Similar to MinErrorToSendNear, this is the more important value that determines how smooth far away units move. I actually make this value much lower than the default to make sniping on my servers SUPER smooth.

MinErrorToSend=0.0019999994;

MaxCustomFileSize

Users with custom faces or custom sounds larger than this size are kicked when trying to connect.

Use this wisely as it can be the cause of alot of Join in Progress lag.

1600000 = 160k

This setting is set to 0 by default in DayZ, modifying it will allow clients with custom skins to connect to your server. I don't recommend allowing this, as it causes massive lag on connection since it forces all players to download the custom skin whenever someone with one connects.

MaxCustomFileSize=0;

Easter Egg

Now that all that silly stuff is done, let's add a custom value that is not in the config by default. Add the following to the bottom line of the arma2.cfg:

class sockets{maxPacketSize=2048;};

This will increase the maximum accepted packet size of the game from 1430 bits to 2048 bits (the max for this engine). Although this can lead to inconsistent performance issues on servers which run multiple ARMA2 missions/games, it is a big help to DayZ servers which love to send fat packets, especially on connect when all the vehicles / tent locations are downloaded to the client. **

** You will also need to add this value in your dedicated server ARMA2's CLIENT configuration. (Documents/ArmA 2/ArmA2OA.cfg)

While we're in your ARMA2's client configuration, let's also append the min/max bandwidth in there to the same values you set in your server config. (Just paste them in anywhere in the file).

----------------------------------------------------------------------------

This concludes the guide for now. I will add more tips and tricks if I get a positive enough response. Feel free to post any feedback, questions, concerns (or complements!) in the thread. Also, could I get a like for a sticky? :)

Edited July 31, 2012 by Guest

[iogc_broadsword 33]

Some really good points there mate, have some beans,

[Guest]

Some really good points there mate, have some beans,

Thanks mate, I do what I can :).

[Guest]

-bump- I need more lagless servers to play on!

[ryahn 112]

I will be doing this on my servers.

[paronity 83]

Very nice and detailed guide. Love it. Will be using some of this on our servers. Thanks and enjoy the beans.

[Diederik 68]

Great guide, support this thread guys for a sticky!

[Guest]

I will be doing this on my servers.

Very nice and detailed guide. Love it. Will be using some of this on our servers. Thanks and enjoy the beans.

Great guide, support this thread guys for a sticky!

*tips hat*

Thanks for all the support, I'll add on to this guide some more tomorrow :D.

[ElRolle 97]

Windows isn't a very good platform (especially by default) for hosting servers. It has a cap of 2GB (or 4GB on 64bit) RAM allocation per process, and has none of the advanced performance tuning tools that come built in to Linux machines.

False statement. The 4GB RAM cap is for 32bit applications and is the same for Linux, it is an addressing limitation, regardless of OS.

This is probably the biggest thing that there is to optimize; windows networking is TERRIBLE for servers by default, even on Windows 2008 Web edition.

False statement. There are no noticable performance differences in network routing/processing or tunneling between Windows Server and Linux.

Go ahead and snatch TCPOptimizer for your version of windows [...]

You realize ArmA2 server mainly use UDP for communication? Optimizing TCP values seems... pointless.

Although it's said that your MaxBandwidth should be slots x 512KB, I think that's bullshit for dedicated machines only running 1 server. I set my max bandwidth to my network speed in bits. (1GBps)

This will kill your upload speed, but if you're only running ArmA2 server on the box I guess it's ok.

This will increase the maximum accepted packet size of the game from 1430 bits to 2048 bits (the max for this engine).

This won't change anything as most networks use standard MTU of 1500, unless jumbo frames are enabled (requires high-end hardware).

Overall nice guide, but quite biased towards Linux and how better it is than Windows. Linux a good OS overall, but Windows Server 2008 isn't that bad either. I will try the -noCB parameter though :)

[Guest]

Feel free to make a better guide then Rolle; all I know is these settings have worked wonders for my servers :). Also, ARMA2 / DayZ does indeed use TCP... use a network monitor; why do you think you need to open TCP ports for the game to work?

There are no noticable performance differences in network routing/processing or tunneling between Windows Server and Linux.

By default perhaps not, but there sure can be if you actually know how to use Linux...

Edited July 30, 2012 by Guest

[ElRolle 97]

Feel free to make a better guide then Rolle; all I know is these settings have worked wonders for my servers :). Also, ARMA2 / DayZ does indeed use TCP... use a network monitor.

By default perhaps not, but there sure can be if you actually know how to use Linux...

The ArmA2 game engine uses UDP for network communication. That's why we have so called desync ingame, as packets are not ACK'd and delivery is not reliable. TCP you are seeing is probably server browser traffic and queries. Notice how you don't have to port forward TCP for ArmA2 servers?

Also I can't write a better guide, I'm a newbie at hosting ArmA2. I'm a network engineer though and just wanted to point out some errors in your guide. Lots of love <3

/Rolle

[Guest]

The ArmA2 game engine uses UDP for network communication. That's why we have so called desync ingame, as packets are not ACK'd and delivery is not reliable. TCP you are seeing is probably server browser traffic and queries. Notice how you don't have to port forward TCP for ArmA2 servers?

Also I can't write a better guide, I'm a newbie at hosting ArmA2. I'm a network engineer though and just wanted to point out some errors in your guide. Lots of love <3

/Rolle

-shrug-

The hive has crazy issues if I don't forward TCP on the ports; which is also where the most network bottleneck is, hence the need for optimization to that connection type.

Edited July 30, 2012 by Guest

[paronity 83]

Yeah - most FPS games or anything like this uses UDP so that broadcasting to multiple sockets is easier.

[Guest]

Yeah - most FPS games or anything like this uses UDP so that broadcasting to multiple sockets is easier.

TIL ;D. Modified guide so it's more clearly explained.

[Sna.ke 43]

Yeah - most FPS games or anything like this uses UDP so that broadcasting to multiple sockets is easier.

UDP is used in games because TCP has such a high overhead. Having to confirm receipt of packets and resend if failed is not really ideal and is actually detrimental to the game client.

It's better for UDP's "connectionless" protocol, where the server can send and forget. If the client doesn't receive packets it doesn't matter to the server. If the client doesn't send packets, the server just keeps the projectile/player moving on the same trajectory as it was moving before. As long as the server keeps the latest valid it's fine.

I've noticed that ARMA2 operates a little differently in this scenario, but I'm not an ARMA2 developer so I can't really speak to that.

Anyways, most games do use TCP for some traffic and communication. The most common use is to capture PING to the server.

One other thing, Windows does have a default cap on the number of connections it can make/keep alive. This is related to TCP connections though, and would not affect UDP. I have not seen a Linux implementation with this. (Source: I've run into this on an application before, where the number of connections exceeded this arbitrary cap. A registry adjustment and a server reboot fixed the issue)

Slightly unrelated topic: I've seen several times references to kicking people for high Ping (getting ridiculous now as kicking for > 100ms). Why? Maybe this is from old engine technology, but I know an Epic developer had an article a long while back about why kicking people for high ping on a server that relies on UDP traffic is a dumb idea. I just assumed that ARMA2 relied on TCP so ping was more relevant?

Edited July 30, 2012 by Sna.ke

[Guest]

UDP is used in games because TCP has such a high overhead. Having to confirm receipt of packets and resend if failed is not really ideal and is actually detrimental to the game client.

It's better for UDP's "connectionless" protocol, where the server can send and forget. If the client doesn't receive packets it doesn't matter to the server. If the client doesn't send packets, the server just keeps the projectile/player moving on the same trajectory as it was moving before. As long as the server keeps the latest valid it's fine.

I've noticed that ARMA2 operates a little differently in this scenario, but I'm not an ARMA2 developer so I can't really speak to that.

Anyways, most games do use TCP for some traffic and communication. The most common use is to capture PING to the server.

One other thing, Windows does have a default cap on the number of connections it can make/keep alive. This is related to TCP connections though, and would not affect UDP. I have not seen a Linux implementation with this. (Source: I've run into this on an application before, where the number of connections exceeded this arbitrary cap. A registry adjustment and a server reboot fixed the issue)

Slightly unrelated topic: I've seen several times references to kicking people for high Ping (getting ridiculous now as kicking for > 100ms). Why? Maybe this is from old engine technology, but I know an Epic developer had an article a long while back about why kicking people for high ping on a server that relies on UDP traffic is a dumb idea. I just assumed that ARMA2 relied on TCP so ping was more relevant?

Very informative, thanks for the information :).

[meta87 25]

Will be applying this guide to my current dedicated box. However I currently only have 100MB connection compared to your 1GB and I also run 2 DayZ servers.

What do you recommend differently than what the guide purposes for our specific bandwidth?

We also do automated reboots of our servers every 6 hours. However most of the time a reboot causes our tents and vehicles to disappear until next reboot. Any idea on what is the cause of this?

Edited July 30, 2012 by Meta

[Guest]

Will be applying this guide to my current dedicated box. However I currently only have 100MB connection compared to your 1GB and I also run 2 DayZ servers.

What do you recommend differently than what the guide purposes for our specific bandwidth?

We also do automated reboots of our servers every 6 hours. However most of the time a reboot causes our tents and vehicles to disappear until next reboot. Any idea on what is the cause of this?

Hey Meta,

• If you're running two servers, your MaxBandwidth should follow the recommended formula of (slots x 512KB).
  
• The bug you're describing is a glitch that occasionally occurs if your server tries to connect to the hive too quickly after shutting down. I recommend adding a 10-30 second sleep function after shutting down your server, before starting it back up.
  

[Alfie (DayZ) 8]

Just wanted to add something about exThreads. Imo you shouldn't set exThreads to 7. As you know exThreads is a mask for a parameter table, not an incremental count. That is, setting it to 7 doesn't create seven additional threads for better threading. The options are 0, 1, 3, 5, and 7:

0: No additional threading.

1: Threading for file operations only

3: Threading for file operations and textures

5: Threading for file operations and geometry

7: Threading for file operations, geometry, and textures

The reason you don't set it to 7 (and I don't know why the DevTeam defaults it to this, it absolutely perplexes me) is because A2/OA are single-threaded applications with basic multithreading functionality added, they don't properly create parallel threads native to the application, they basically rely on OS scheduling.

That means that when you launch the server with -exThreads=7, you're telling the server to prepare core scheduling for geometry and texture processing on a render loop that will never, ever come on the server. You're creating overhead for absolutely no reason, and zero gains.

exThreads 1, however, uses only file operations. File operations are *mostly* used to handle the other two threads (geo and tex), but only because those are the most-called file operations. It handles all file operations. If you have the overhead to spare, you will notice marginal performance and stability gains as it offloads the file operations process from the main process. If, on the other hand, you don't have the overhead, it will destabilize the server.

In other words, never use anything but -exThreads=0 or -exThreads=1 for the server. You also actually do need to specify this, because the .exe WILL use auto-detection to try to determine the exThreads number based on your core count.

Nice guide though. +beans

[alexhjelm 2]

This didnt work at all, our servers got 1-3 min loading times when we had 2-5 sec from the start.

[Sna.ke 43]

We also do automated reboots of our servers every 6 hours. However most of the time a reboot causes our tents and vehicles to disappear until next reboot. Any idea on what is the cause of this?

How do you shutdown your server? Does your script kill the process or is a "#shutdown" initiated?

I've heard of these issues occurring, and I heard it was related to improper shutdowns. The best way to restart your server is to get BEC to initiate a #shutdown and let a restart script see your server offline and bring it back up.

[Guest]

How do you shutdown your server? Does your script kill the process or is a "#shutdown" initiated?

I've heard of these issues occurring, and I heard it was related to improper shutdowns. The best way to restart your server is to get BEC to initiate a #shutdown and let a restart script see your server offline and bring it back up.

Yea, this is another good point. In-proper shutdowns can cause syncs with the hive to abruptly stop, causing data loss and corruption.

Just wanted to add something about exThreads. Imo you shouldn't set exThreads to 7. As you know exThreads is a mask for a parameter table, not an incremental count. That is, setting it to 7 doesn't create seven additional threads for better threading. The options are 0, 1, 3, 5, and 7:

0: No additional threading.

1: Threading for file operations only

3: Threading for file operations and textures

5: Threading for file operations and geometry

7: Threading for file operations, geometry, and textures

The reason you don't set it to 7 (and I don't know why the DevTeam defaults it to this, it absolutely perplexes me) is because A2/OA are single-threaded applications with basic multithreading functionality added, they don't properly create parallel threads native to the application, they basically rely on OS scheduling.

That means that when you launch the server with -exThreads=7, you're telling the server to prepare core scheduling for geometry and texture processing on a render loop that will never, ever come on the server. You're creating overhead for absolutely no reason, and zero gains.

exThreads 1, however, uses only file operations. File operations are *mostly* used to handle the other two threads (geo and tex), but only because those are the most-called file operations. It handles all file operations. If you have the overhead to spare, you will notice marginal performance and stability gains as it offloads the file operations process from the main process. If, on the other hand, you don't have the overhead, it will destabilize the server.

In other words, never use anything but -exThreads=0 or -exThreads=1 for the server. You also actually do need to specify this, because the .exe WILL use auto-detection to try to determine the exThreads number based on your core count.

Nice guide though. +beans

Very helpful information, edited guide. Thanks!

[peep 46]

Thanks for this, I haven't been having any performance issues so far but that's even better because these settings likely won't hurt anything negatively.

[azunai 32]

Yea, this is another good point. In-proper shutdowns can cause syncs with the hive to abruptly stop, causing data loss and corruption.

Very helpful information, edited guide. Thanks!

your quote of the full start.bat is still wrong :)

uhm jeah seems like mysql server dont like some changes, idea which one ?

Edited July 30, 2012 by azunai

[Guest]

your quote of the full start.bat is still wrong :)

uhm jeah seems like mysql server dont like some changes, idea which one ?

Why are you running local MySQL? Private hive? :o