JayC

You took a 15% performance hit... The way ArmA2 server is currently written, it only uses 1 core for networking, and 1 core for AI, so the single most important factor in large servers is single core speed. If you were running 60 users before without problems, then you're be limited to 50 at best under the new system. You can look into network settings on your server to see if you can help with the desync some, but the fact is a E5-2690 isn't as fast as a E3-1270 for ArmA2.

First, I'd like to know how you guys are getting private information out of BIS when the rest of us can't get any updates on the linux server situation? What? It's not hosting and the linux distro that is the issue... It is software BIS released that crashes on a regular basis with glibc errors on any distro, including the one they posted as using for their build system. I for one won't pay a single red cent for BIS to support a feature of the product I've already purchased. As for it's the dozen distro's that are the problem... no it's not.. BIS needs to build a stable work linux dedicated server and release a list of dependencies for that server... server admins in the community will quickly figure out how to get it working on our end no problem. Linux isn't a mystery to get working... the linux dedicated server has been running just fine on a dozen or more distros for years with no problems, we just need a stable build and we'll figure the rest out.

You want to look for a Xen based VPS, not a KVM or similar style... Xen based is much harder to over subscribe... You're going to need about 2.0-2.5ghz of cpu, and 1.5 gigs of memory to run a 16 slot server... you should be able to find this with Linux for around $30 a month, and with Windows around $50. (Also Amazon EC2 is a good option) And trust me you get a lot more flexibility hosting your own server. If you need a hand picking a host or any of the technical details, feel free to PM me and I'll be happy to help you out.

As stated by the Dev's before, there is a library they are using which requires newer glibc versions than is currently on CentOS 5.x, or even CentOS 6.x... They wouldn't have gone to the trouble of upgrading their official build system if that library wasn't a requirement for moving forward. If you look in the first 1.62 alpha thread they list the exact version of Debian they're running on the build system. The issues with glibc crashes are most likely coding issues inside of the BIS code (or supporting library's) and have little to nothing to do with the Linux distro you're running. I think the chances that 1.62 will ever run on CentOS 5.x are slim and none (based on statements made by the Devs), CentOS 6.x may be possible with this build, if not should be possible in the coming weeks and months as RHEL/CentOS back port glibc. I'm frustrated just as much as you are about the current situation, and the huge performance hit, and cost increase with the possibility of needing to migrate to Windows... but, the glibc crashes don't appear to be distro related, nor glibc related, but most likely coding issues/bugs in the BIS code they are most likely working on. ---------- Post added at 02:15 ---------- Previous post was at 01:17 ---------- Overlord, First, I'm well aware that 1.60GA works great, even some of the 1.60MP betas that came after it are very stable... but, steam users were forced to upgrade to 1.62, and there is not a stable process that an average user can perform to revert to 1.60 on Steam... in our clans case that means 65-75% of the players are stuck on 1.62GA. So we're left trying to figure out how to get these 1.62 alpha's to work. Upgrading packages on Debian and Ubuntu is a piece of cake... CentOS isn't any harder... the problem is that for certain versions of these distro's there are NO patches which upgrade the glibc to the correct version... CentOS 5.x which had been very popular among linux server admins for example can't be upgraded with patching to the correct version of glibc. Compiling glibc upgrades by hand aren't something a novice server admin should be doing (although as stated earlier, chroot is an option - but again not for most novice server admins). I think most of these guys are smart enough to install patches if that was the answer.

Most people shouldn't be recompiling glibc on their servers... very bad things can happen if you don't know exactly what you're doing. Most likely the errors we're seeing have to do with BIS code/libs, and not gblic libs on the servers in question, which is why EVERYBODY is seeing crashes (I'm not aware of anybody who is not having crashes using this alpha - if somebody isn't experiencing crashes, please post so we can figure out what you're doing differently than the rest of us). Which 'official release' would you suggest we run?

I'm hoping that we'll get a response from the Devs on if they need/want the core dumps, and what other information they need from us to help them.

Is that the official way to send core dumps to BIS?

Not to beat a dead horse... But is there a way for server admins to upload the core dumps from the crashes? Would this help with the development process at all? (I'm assuming maybe since adding core dumps was part of the change log for this alpha) If not, no big deal, just trying to help anyway we can.

The last GA server was 1.60, there were a number of 1.60 MP betas after that... all of those seem to run reasonable well to great... problem is only clients who aren't on Steam, and haven't upgraded to 1.62 can access servers running that code. For clients running 1.62GA there have been 2 releases in the last month of "unstable alpha" software which for most server admins is crashing on a fairly regular basis... Every now and again I'll see a run of 5-10 hours without a crash, then it will crash 5 times in the next hour.

Yes, I realize that reality is such an unwelcome fact... but the fact is that WINE is *always* going to be slower than the native Linux server. And our testing backs up that fact, seeing performance 12-13% slower running 1.62GA windows server via wine, and running the unstable alpha 1.62 linux server and about the same compared to 1.60 GA linux server. In all fairness, WINE is slightly better at running the 1.62GA than running it on windows 2008r2... So it's not that WINE is a bad program, using it for this type of task though is a horribly bad idea IMHO. So yes every time you suggest wine, I come by and remind people that wine isn't a good choice for running high end servers.... anything running MSO needs a fairly high end cpu, and wasting 10-15% of it on unneeded overhead isn't a good idea IMHO. And just so I don't be accused of trolling... lets refer to the Wine WIKI http://wiki.winehq.org/Debunking_Wine_Myths You'll note that even the Wine folks admit that technically wine is always going to run slower than a native Linux application... that it some cases running a windows application via wine can be faster than running via native windows... but wine is never going to be as fast as a native Linux application. You'll note the second note, the reason wine + unix is sometimes faster is because unix/linux often has such a huge performance boost over windows to begin with, wine's extra overhead isn't such a bad performance hit. With the way the dedicated server is currently written, any overhead reduces the max number of players the server can support... a 15% performance hit running MSO can make a 3.0ghz cpu core, seem like a 2.5ghz cpu core... which means you go from 25-30 players down to 15-20... it's a big performance hit anyway you cut it.... and at core speeds above 3.0ghz, you're really talking a steep cost difference to gain that 10-15% back... going from an E3-1230V2 to an E3-1280V2 is a $600-700 cost increase, just to make back the overhead introduced by wine (and to the same extend windows 2008r2).

What operating system? That is going to be the key question... We run an E3-1270V2 which is a good bit faster that this system... and it can handle complicated missions with mods (ace, acre, rh, etc)... up to about 65-70 players on Linux... on windows 2008r2 testing shows about 50-55 players on the same hardware. I'd suggest looking for an E3-1230V2 it's going to give you slightly better performance, and should be available for about the same price. Otherwise, it should work ok for the setup you want.

1. who knows, but it's a good question 2. again who knows, I'd hate to see what not 'fully supported' means... 3. MSO issues are an MSO choice, not an issue with the Linux server... they choose a windows only solution, that one isn't on BIS. But from the looks of it, if you want PDB you're going to need to go Windows. 4. No, expect at least a 10-15% drop in performance under Windows, and remember that Windows is a serious resource hog. 5. WINE is not a good choice IMHO, you're going to see a serious performance hit with it as well. It's sad that a lot of folks are having to ask these questions... BIS should be doing more to get a stable beta out for Linux. ---------- Post added at 20:07 ---------- Previous post was at 20:04 ---------- I'm not aware of any dedicated server provider that doesn't give you root on linux? Even with the issue under 1.60 linux out performed windows by a wide margin.... with proper tuning on BIS's part, Linux should run circles around the windows server.

Only if you want to take a serious performance hit.

Lucky79, It's not a problem with your setup, but an issue with the server released by BIS... it's an unstable alpha for a reason :) Save the core files along with the log output from the crash in case they tell us where to upload the files... This version is not stable enough for even testing, let alone production use.

These are almost certainly errors in the server code, there is nothing wrong with your setup.... Save the core files for if/when they tell us where to send them... As of right now, this alpha is not stable enough for even light production use. I'm running it just purely to collect core dumps... which are happening 8-10 times a day on a public server.

Welcome to the unstable Linux alpha... It's happening to all of us.

Again, the only SAFE way to upgrade from 1.60 to 1.62 is to do a complete upload from a fully patched windows system... Taking short cuts if you don't know what you're doing causes issues... Another method that would work, is using rsync... but again if you're not comfortable with Linux and command line I wouldn't recommend it. As for your error, it appears you're trying to run a 1.60 version of arma2oaserver with 1.62 files? That won't work.

Where should we send core dumps? Because it's crashing just as often as the previous alpha.

There is your problem... You need this: http://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-dvd/

I'm not up on Cisco ASA's, so I can't tell you what the command line is... but the problem is fixable on them... You need to set a source port rule on the outbound NAT to use static mapping... so if an inbound packet on 230x is shown as outbound on the same port... This happens on a lot of routers with UDP packets.

Exactly which Debian branch did you install? Try doing a full patch and see if that fixes the problem...

This how-to should get you up and running: http://www.apollon-domain.co.uk/?p=221 While it's for Ubuntu 10.x it works fine for 12.x As for updating from 1.60 to 1.62, no the only safe way to do an upgrade is to completely re-upload a copy from a patched windows system. If you're having trouble with the install I'd strongly encourage you to follow this safe method instead of trying to take any short cuts. As for the 'unstable' alpha for 1.62 on Linux, it crashes a *lot*, about 50-60% (from my experience) of the time watchdog catches the crash and is able to reset the arma2 server, the rest of the time, the crash hangs the server, requires that the process (of both the watchdog and arma2oaserver) be killed by hand and then restart the server... If you're not comfortable with finding the process ID and killing it from the command line, you may wish to wait for a more stable Linux dedicated server to be released. If you need a hand getting linux setup send me a PM I'd be happy to hop on skype with you and walk you through the install.

How many slots do you want to run? What is the uplink on your adsl? As for the machine, the key to hosting lots of players is cpu core speed, since today most of the AI related tasks aren't fully multi-threaded, having a high clock rate gives you better performance when hosting... memory isn't much of an issue for a single game, 2 to 3 gigs should be plenty if there is nothing else running on the server... again bandwidth and cpu clock rate are the two key issues that will limit you.

It doesn't... it's about 3 patches behind what is needed to run the current alpha... figure 6 to 8 months before patches will be out for centos 6.x

First, nobody is whining about false advertising... People keep making the statement that somehow the linux dedicated server was "developed and delivered out of goodwill from BIS" and that just isn't the case, it was part of the advertised product from day one. As for BIS working on the Linux biniaries, from the sounds of it nobody has been working on the Linux server for the last week: http://forums.bistudio.com/showthread.php?138230-Linux-1-62-95577-alpha&p=2204991&viewfull=1#post2204991 The frustration is that BIS is not IMHO providing enough support to the Linux dedicated server, Steam users were forced to patch to 1.62, so 1.60 servers are dead because a large % of people can't play it.... Yet, BIS has only managed to release 2 Linux dedicated server patches in the last month, the 'unstable' alpha and 1.60.94743 released on July 11th. In that same time BIS has managed to release (by my rough count) 15 windows dedicated server patches. 5 or 6 of which since 1.62 patch was released... yet somehow it's ok for linux server operators (and the large clans they represent) to be forced to sit on the sidelines, while all of the resources are poured into windows server development while our servers are unable to run 1.62 on a stable platform. Mistakes happen, we know a couple happened in this case... we have a very rough idea of what happened in this case... none of which as a customer and Linux server admin make me feel more comfortable with the situation... Either way, the linux dedicated server admins here are offering to help in anyway we can, but there needs to be more forward progress in getting linux dedicated servers up to atleast the 1.62 with *all* the same features of the windows dedicated server.