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.