ArmA 1.12 Linux Dedicated Server Public Beta

[maruk 80]

New ArmA 1.12 Linux Dedicated Server Public Beta build 5254

It requires all data from 1.12 public beta version (as installed to beta subfolder).

armedassault.com (~4 MB)

WARNING: THIS IS AN INTERIM PUBLIC BETAVERSION. IT'S NOT A FULLY TESTED STABLE RELEASE. USE IT AT YOUR OWN RISK. DO NOT CONTACT OFFICIAL SUPPORT WITH ANY PROBLEMS USING THIS PATCH BUT USE ONLY STANDARD COMMUNITY CHANNELS TO GIVE US FEEDBACK.

Copyright © 2008 Bohemia Interactive. All rights reserved.

Quote[/b] ]

Changelog:

5254 - Fixed: BattlEye issues while using server.cfg on Linux dedicated server

5254 - Fixed: Heap size detection on Linux (causing config file problems and low server FPS)

[viper.cless 1]

Thank you.

I just installed the new version and it solved the fps issue on my server

[Buzz 0]

Thanks BIS

[cleanrock 0]

New 1.12 seems to have fixed both the problems i have seen (low FPS and config problem).

[SoldierIsNotHistory 0]

New 1.12 solve low FPS and IA issues.

Good game

[=jps=sgtrock 4]

I just got an installation set up yesterday and played through one of the small default co-op missions just to check things out.  No additional mods on it yet.  Performance was great for just me.  Hardware and software information:

uname output:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">jim@llama ~ $ uname -a

Linux llama 2.6.22-gentoo-r9 #8 SMP PREEMPT Fri Feb 29 23:55:49 CST 2008 i686 Intel(R) XEON(TM) CPU 2.40GHz GenuineIntel GNU/Linux

vmstat output:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">jim@llama /opt/arma $ vmstat -S M

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----

r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa

1  0      0   1234    207    316    0    0     6     4   11   11 19  1 80  0

Output from top:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">top - 16:22:48 up 12:35,  1 user,  load average: 0.69, 0.48, 0.43

Tasks:  66 total,   1 running,  65 sleeping,   0 stopped,   0 zombie

Cpu0  : 56.4%us,  0.2%sy,  0.0%ni, 43.5%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st

Cpu1  : 22.5%us,  1.5%sy,  0.0%ni, 76.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st

Mem:   2075208k total,   811304k used,  1263904k free,   212144k buffers

Swap:  3903712k total,        0k used,  3903712k free,   324576k cached

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  P COMMAND

5356 jim       21  -4 87748  68m 9320 S   75  3.4 299:49.57 0 hlds_i686

14600 jim       15   0 61680  27m 6440 S    5  1.4   0:13.33 1 server

14669 jim       15   0  2256 1104  860 R    0  0.1   0:00.03 1 top

4455 jim       18   0  3068 1488 1180 S    0  0.1   0:00.01 0 hlds_run.steam

14464 jim       15   0  8400 1596 1036 S    0  0.1   0:00.08 0 sshd

14465 jim       18   0  3332 1704 1356 S    0  0.1   0:00.03 1 bash

Not bad numbers for an idle server, eh?     Next thing to do is see if I can't get it loaded up with the vegetation mods, some realism mods, a couple of mission packs, and a bunch of people!  

Couple observations above and beyond the Linux specific results.  This is my first time running an ArmA server, so I may have missed something when I was going through the wiki and other documentation.  

First, there doesn't seem to be any way to assign admin except for blanket privileges.  Worse, I could only assign a single default password for admin.  

I commented on this particular issue at some length over a year ago, so I won't go into it here except to observe this makes granting admin rights to a large number of people problematic, at best.  My experience over the years has been that the more admins capable of kicking and banning griefers that you have, the more popular your server becomes because people know they can trust it to be kept clean.  

However, having a bunch of admins on means that the tools have to be there to figure out what the real story is if there's an accusation of someone abusing their privileges.  This is easily met as long as there's a log trail of admin activity combined with unique identifiers.

Second, there's apparently a wide disparity in how much bandwidth per player is actually required to run a server versus downloading content.  I read one poster who stated that normal play only consumed between 5 and 13 Kb/s per player, while DL'ing content for a single player could easily max out a 10 Mb/s Ethernet interface.  He warned that meant that the server would be starved for CPU cycles and/or network.  The net result could be unpredictable lag spikes for all players.  I find this a bit disconcerting as my ISP currently limits me to a half duplex 10 Mb/s Ethernet interface, which in turn means that my effective max throughput is about 4.5 Mb/s.

Valve Software solved this particular problem nearly 10 years ago by allowing download requests to be redirected to a webserver which didn't even have to be running on the same server.  I've found that running an Apache server on the same box as my Half-Life and HL2 based gameservers was still sufficient to eliminate lag spikes.  One reason seems to be that Apache's netcode degrades gracefully as the process finds itself in contention for networked bandwidth.  Either that, or the OS is able to balance bandwidth requirements better across multiple processes.  

Anyhow, I'd like to know if there's a similar means of redirecting at least the static mission information to an external source?  Does it exist and I just missed it somehow?

Thanks again for finally getting this up!  I do appreciate the effort tremendously.