Actium

I'd recommend to simply replace the steamclient.so in your arma directory with the one from the linux32/-directory within your SteamCMD installation. This (mine, includes details on above steamclient.so workaround) and this bug report have already been acknowledged/assigned, so there might be an official fix soon. Regardless of that its quite embarassing to release a game update without properly testing the dedicated server first. Everyone with an eye patch and no hearing would have noticed this bug, if he'd tested the dedicated server binary on a real dedicated server.

The BIKI's just awesome ... NOT. They managed to run it with an expired SSL certificate a few days ago. Not too long ago I read a thread assuming, that the BI developers themselves don't have a broad understanding of their engine's network configuration. I wouldn't be surprised if this were close to the truth. Okay, back to the business at hand. Let' first quote the relevant sections of the basic.cfg BIKI: The following is my assumption on the topic, based on my technical background knowledge (B.Sc. in information technology and 10+ years of experience administrating dedicated linux severs) and a little common sense. Considering the lack of information from the official side, I cannot and will not guarantee that it's close to perfect or even correct. MinBandwidth: Considering the – let's call it very conservative – default value this is indeed the utmost important parameter for optimization, since any decent dedicated server will have at least a 100 Mbps link, although 1 Gbps appears to be de facto standard nowadays. Since the "Bandwidth the server is guaranteed to have" is asked for and I understand it as the available bandwith in a worst-case scenario, I'd use the following formula: MinBandwith = (MIN($GUARANTEED_DOWNSTREAM_BPS, $GUARANTEED_UPSTREAM_BPS) - $RESERVED_BANDWITH) / $NUM_ARMA_SERVERS; // $GUARANTEED_{DOWN,UP}STREAM_BPS is the upstream/downstream bandwith guaranteed by your ISP. // This need not neccessarily be your link speed¹. // $RESERVED_BANDWITH is the bandwith reserved for anything else running on the same server // (e.g. teamspeak, webserver, other gameservers, etc.). // $NUM_ARMA_SERVERS is the number of ArmA servers running with these exact settings. // If you wanna go pro, you could allocate more bandwith to prioritized servers and less to the rest. // Just make sure the sum is always lower than your guaranteed bandwith. ¹) For example my ISP hetzner.de uses 1 Gbps links, but only guarantees 200 Mbps bandwith (although I've never had any trouble maxing out the 1 Gbps during benchmarks). MaxBandwidth: This is the best-case scenario bandwith to complement the worst-case above. I assume setting this to anything higher than 100 Mbps will have any noteworthy effect, since a game server should hardly ever need to send that much data to clients, but setting this to your maximum available bandwith shouldn't hurt either. However I'd really like to know how much bandwith one of these 100+ slots Alltis Life servers usually eats up (average and peak values). The bandwith usage may even be higher if a lot of AI units and human players are close (since in this case the units' positions must the sent to every client). Regardless of that, it's formula-time again: MaxBandwidth = MIN($DOWNSTREAM_BPS, $UPSTREAM_BPS); // ${DOWN,UP}STREAM_BPS is the best-case bandwith available to your server. // Use your link speed or some (more or less generously rounded up) benchmark results. In case anyone is of a different opinion, feel free to discuss it. I'd really appreciate to hear technical arguments or even hard facts (e.g. bandwith usage statistics).

I'd really like to read Inch's clarification, because it's just plain wrong if not absolutely absurd. The limited 32-bit userspace virtual address space has – if at all – a negligible effect on socket performance. I coded a quick'n'dirty example to put this to the test, that transmits 1 million MTU-sized UDP-packets over the loopback¹ interface. The test is conducted 10 times to gather AVG±STDEV. 32-bit speed: (3823.4 ± 49.1) Mbps 64-bit speed: (3924.6 ± 52.0) Mbps Looks like the resulting ~4 Gbps are just slightly above your 100 Mbps theoretical limit. The relative difference is – just as expected – negligible (~2.6%) and the STDEVs even almost touch. Please do not post such blatantly false information if you lack an in-depth understanding of the technologies involved. Some ppl looking for accurate basic.cfg information (which the wiki definitely lacks) might actually believe you and mess up their config even further. Here comes the source² code, just in case anyone would like to verify my findings. /* * Copyright (c) 2014 Actium * * Permission is hereby granted, free of charge, to any person obtaining a copy * of this software and associated documentation files (the "Software"), to deal * in the Software without restriction, including without limitation the rights * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell * copies of the Software, and to permit persons to whom the Software is * furnished to do so, subject to the following conditions: * * The above copyright notice and this permission notice shall be included in * all copies or substantial portions of the Software. * * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN * THE SOFTWARE. */ #define _POSIX_C_SOURCE 200809L #include <errno.h> #include <netinet/in.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/socket.h> #include <time.h> #include <unistd.h> #define ERR_CODE 1 #define BUFSIZE 1500 #define NUMPKTS 1000000 #define LIKELY(x) __builtin_expect(!!(x), 1) #define UNLIKELY(x) __builtin_expect(!!(x), 0) #define Err(status, format, ...) do { \ fprintf(stderr, "%s:%d: " format ": %s\n", __FILE__, __LINE__, ##__VA_ARGS__, strerror(errno)); \ exit(status); \ } while (0) int main(/*int argc, char *argv[]*/) { socklen_t addrlen = sizeof(struct sockaddr_in); struct sockaddr_in dest_addr = { .sin_family = AF_INET, .sin_port = htons(1234), .sin_addr = { htonl(0x7F000001) } }; int sockfd; if ((sockfd = socket(AF_INET, SOCK_DGRAM, 0)) == -1) Err(ERR_CODE, "socket(AF_INET, SOCK_DGRAM, 0) error"); struct timespec before, after; if (clock_gettime(CLOCK_MONOTONIC_RAW, &before) == -1) Err(ERR_CODE, "clock_gettime(CLOCK_MONOTONIC_RAW, %p) error", &before); char *buf = (char *) malloc(BUFSIZE); for (int i = 0; i < NUMPKTS; i ++) { if (UNLIKELY(sendto(sockfd, buf, BUFSIZE, 0, (struct sockaddr *) &dest_addr, addrlen) == -1)) Err(ERR_CODE, "sendto(%d, %p, %u, 0, %p, %u) error", sockfd, buf, BUFSIZE, &dest_addr, (size_t) addrlen); } if (clock_gettime(CLOCK_MONOTONIC_RAW, &after) == -1) Err(ERR_CODE, "clock_gettime(CLOCK_MONOTONIC_RAW, %p) error", &before); close(sockfd); long delta_ns = 1000000000 + (after.tv_nsec - before.tv_nsec) % 1000000000; double delta_s = after.tv_sec - before.tv_sec + (double) delta_ns / 1000000000; double mbps = (double) BUFSIZE * NUMPKTS * 8 / delta_s / 1000000; printf("%.0f Mbps\n", mbps); return(0); } ¹) Using a physical NIC is pointless, since both versions easily saturate the link. ²) This is Linux code, since I don't do Windows network programming. But if your theoretical limit were indeed a theoretical limit, it would apply regardless of operating system. PS: Please also correct your wrong understanding of SI-prefixed bitrates (Gbps, Mbps, etc.). Nuxil's absolutely right. See this or read IEEE 802.3. It might also surprise you, that the actual throughput is even lower. The advertised bitrates only apply to OSI Layer 1.

Maybe some of you server admins have also stumbled upon at least one of these issues (the list can probably be extended until the Last Judgement occurs) related to ensuring law and order on your server: Thinking about the issues properly, I figured out that the only way of circumventing that shortcoming of the armed assault server, is creating a database that correlates player ids, names and ip-addresses. Since I'm quite skilled in coding perl* scripts I just implemented the idea of creating such a database in three perl scripts. One for creating/updating the database: user_db_create.pl One for dumping the database in a human-readable format: user_db_dump.pl One for merging serveral databases (enabling exchange of the database between several admins): user_db_merge.pl Feel free to use/modify/sell/throw away these scripts as you like. Just as my comments say it is under Public Domain and hence you can do with it whatever you want (I'd however appreciate some credits). What I'd really like to know is how this piece of software can be improved and what your general opinion about such a database is. Bug reports are also appreciated (FYI: I cannot guarantee that this script will not fry your computer. It's just very unlikely.). * I'm afraid you poor windows users will not be able to use it. (No guarantee though. I just do not have any experience with active/strawberry perl).

I'm still having issues figuring out what the ideal linux kernel configuration concerning the arma linux dedicated server's performance is. What I've found out so far: A real server configuration (No Forced Preemption + Timer frequency = 100 Hz): Causes the server to take ages for even loading a map. When you try to connect to the server and have successfully selected a mission you will be stuck at the "Wait for Host"-screen (the one with the progress bar) for more than 5 minutes. During that time the server's cpu load is as low as 0% and memory usage climbs very, very slowly. Low-latency desktop configuration (Preemptible Kernel + Timer frequency = 1000 Hz): Server works quite well, but suffers from very serious JIP- and usual lags. Additionally a server is not supposed to run a kernel that is actually inteded for desktop-use. This configuration makes IO-operations despite the kernel manual's claims ("slightly lower throughput") about 5 times more cpu intensive when compared with the real server configuration (And we do not want that for servers). Compromise A (Voluntary Kernel Preemption + Timer Frequency = 100 Hz): -> Real server configuration (No Forced Preemption + Timer frequency = 100 Hz) Compromise B (Voluntary Kernel Preemption + Timer Frequency = 1000 Hz): Seems to be working quite well. However I just started testing this configuration. Additionally 1000 Hz are not supposed to be used for a server system either. Did anyone else play with different performance related kernel configuration options before? Question to the developers: What configurations is the server intended for?

I have to disapprove that. The linux dedicated arma server is smp capable (it caused 125% cpu load on my machine before), however due to smp's drawbacks concerning data exchange and the general issue of threadability (cheap example: how dou you thread 1+1?) it just cannot utilize an smp system fully.

The drawback of keygety's approach is that the dll-file he created replaces an official dll-file and since nobody knows what that dll really does (implement backdoors, ...) some ppl might hesitate when asked to install it in order to support some player database scripts. Additionally it does not run on linux.

From what I've experience with my game server (arma dedicated linux server) I have to conclude that arma does only partially utilize a systems smp-capability. Although libpthread is compiled into the binary the fact that the cpu load arma causes raises very fast (8 players did suffice) up to 100% (that means that one core is at full capacity), but then it grows very, very slowly up to 125% (even with 32 players on it). in case you use top -H in order to obtain detailed information on arma's threads you will end up with sth like that (I'm afraid i could not get any detailed values for a cpu load as high as 125%): <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">PID USER    PR  NI  VIRT  RES  SHR S %CPU %MEM   TIME+  COMMAND 2099 user    20  0  568m 536m  10m R  62 26.7  1464:10 armad_1.14 2100 user    20  0  568m 536m  10m S   0 26.7  0:00.13 armad_1.14 2101 user    20  0  568m 536m  10m S   0 26.7  4:40.70 armad_1.14 2102 user    20  0  568m 536m  10m S   0 26.7  4:10.14 armad_1.14 2103 user    20  0  568m 536m  10m S   0 26.7  0:51.01 armad_1.14 Main issue of multithreading is that it is very difficult to exchange information between threads which are running on two different cores. Additionally some calculations just are not threadable (due to logic reasons). Try to imagine how to thread 1+1.

Well, let's just see if the FPS-fix is going to solve the JIP-issue. In case it should turn out that the static downloads do still cause lag after that fix has been implemented, such a change in the download system would probably be a lot simpler than finding/fixing the remaining issues in the download system or even reimplementing the whole way of how files are transmitted internally.

Thats not the major problem and major JIP-LAG cause. The major part are game-progress-data and mission-file for players who haven't them on their harddisk. Forcing every player to mirror his custom files on a webserver is in my mind beyond the line of creating minor and endurable disadvantages for the players. (Does every single one of you using custom files have a public webspace? I doubt that.) I've already mentioned the possibility of redirecting static downloads (like maps/mods/etc. no userspace custom files.) to external http-/ftp-servers since their sole purpose is serving files as fast and as efficient as possible and would hence be superior to arma's internal download system (This is how Q3/ET manages file downloads and that system just works without any known disadvantages (besides having to set up a httpd/ftpd - let's all pity the poor admins.).).

A way of improving both server performance and map download speed, would be a configurable option to forward map downloads to an external httpd or ftpd (I'm certain, for example, lighttpd scales much better concerning both load and throughput (due to its non blocking io, use of kernel functions, etc.) in comparison with the arma dedicated server (since that is a httpd/ftpd's purpose)). Another idea for a server-side setting would be a possibility to switch off the deprecated "spawn vehicle (even the one's which have been destroyed for hours) -> exec its init command -> despawn it"-feature.

By just deleting the warfare pbos you might accidently delete the new buildings and units it brought into the game as well (See your mission editor. A bunch of new objects within a group called warfare.) and some of the maps you might play on your server in future could depend on these buildings. I'm not sure if they're really stored within warfare.pbo, you'll probably have to find it out yourself.

Unfortunately ArmA got means of cheating built in (the scripting system). Most servers just don't have verifySignatures set on. Without that everyone can use addons as he likes. It doesn't matter at all if these addons contain a CLI to execute any kind of code or just decent sound modifications or what so ever.

I have - in my opinion - proven, that client side mods are responsible for server crashes. The Sahrani Life Server I'm hosting (Official SL Server #1) has been suffering from frequent crashes. It's a linux box the server runs on and due to linux' very informative nature, i've been able to find out, that those crashes were caused by segment violations. <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">May 18 00:15:57 deimos armad_1.12[20984]: segfault at 305f3931 rip 83215e0 rsp ffd21780 error 4 May 18 22:03:00 deimos armad_1.12[21931]: segfault at 3d343a19 rip 8390608 rsp ffbc17f0 error 4 May 18 22:40:44 deimos armad_1.12[21994]: segfault at 3ca3d7cb rip 8390608 rsp fffcf910 error 4 May 19 17:11:00 deimos armad_1.12[22026]: segfault at 3d7df477 rip 8390608 rsp fff6b0b0 error 4 May 20 15:02:12 deimos armad_1.12[22492]: segfault at 3bbc6b40 rip 8390608 rsp ffb76cc0 error 4 May 21 00:38:55 deimos armad_1.12[25059]: segfault at 3d3852ac rip 8390608 rsp ffb0f460 error 4 May 22 19:00:28 deimos armad_1.14[27682]: segfault at 3c03132f rip 83905c8 rsp ffcfce50 error 4 May 22 20:27:55 deimos armad_1.14[27737]: segfault at 46423fbb rip 83905c8 rsp ffd92ef0 error 4 May 22 20:37:55 deimos armad_1.14[27889]: segfault at fd rip 83905c8 rsp ffdb3e40 error 4 What drew my attention was that the crashes only occured when there were several people on the server. When i checked the server's console log, i stumbled upon this (Repeated for thousands of times. Some of the logfiles were as big as 20MiB): <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">Warning Message: No entry 'bin\config.bin/CfgMagazines.SLX_SmokeGrenadeLauncher'. Warning Message: No entry '.picture'. Warning Message: '/' is not a value Warning Message: No entry '.scope'. Warning Message: '/' is not a value Warning Message: Error: creating magazine SLX_SmokeGrenadeLauncher with scope=private Warning Message: No entry '.displayName'. Warning Message: '/' is not a value Warning Message: No entry '.nameSound'. Warning Message: '/' is not a value Warning Message: No entry '.Library'. Warning Message: No entry '.libTextDesc'. Warning Message: '/' is not a value Warning Message: No entry '.type'. Warning Message: '/' is not a value Warning Message: No entry '.count'. Warning Message: '/' is not a value Warning Message: No entry '.maxLeadSpeed'. Warning Message: '/' is not a value Warning Message: No entry '.initSpeed'. Warning Message: '/' is not a value Warning Message: No entry '.reloadAction'. Warning Message: '/' is not a value Warning Message: No entry '.modelSpecial'. Warning Message: '/' is not a value Warning Message: No entry '.ammo'. Warning Message: '/' is not a value Warning Message: No entry 'bin\config.bin/CfgWeapons.SLX_SmokeGrenadeLauncher'. Warning Message: No entry '.scope'. Warning Message: '/' is not a value Warning Message: Error: creating weapon SLX_SmokeGrenadeLauncher with scope=private Warning Message: No entry '.displayName'. Warning Message: '/' is not a value Warning Message: No entry '.nameSound'. Warning Message: '/' is not a value Warning Message: No entry '.type'. Warning Message: '/' is not a value Warning Message: No entry '.picture'. Warning Message: '/' is not a value Warning Message: No entry '.Library'. Warning Message: No entry '.libTextDesc'. Warning Message: '/' is not a value Warning Message: No entry '.model'. Warning Message: '/' is not a value Warning Message: No entry '.fireLightDuration'. Warning Message: '/' is not a value Warning Message: No entry '.fireLightIntensity'. Warning Message: '/' is not a value Warning Message: No entry '.muzzles'. Warning Message: Size: '/' not an array No owner No owner Since even with the - hopefully - more stable version 1.14 these crashes did not seize to exist, i decided to disallow any kind of clientside modifications. Since that change the server has been running at capacity for 4 hours and for more than a day since its last restart. I'd say that should definitely point out what client mods are capable of.