brightcandle

I have gone through a few different setups for sound for arma 3. My favourite so far is using a SBX Pro on a Soundblaster ZX with 5.1 surround sound which then SBX adjusts to my headphones. That gives me about the best sense of direction in A3 and other games compared to Dolby Headphone with a Xonar and especially compared to the onboard solution or no surround enhancement at all. While we can't get hardware acceleration that doesn't make a sound card useless. The lower sound floor and the surround implementations that take 5.1/7.1 output from the game and then generate output to the headphones is better than just game to headphones directly except in a very small number of games.

So we have a dedicated server install, have been running it since March. However with todays helicopter+ vehicle shooting patch we can't connect to the server anymore. We type the password and then it gets stuck on the next screen, never make any further progress and the server never acknowledges the connection in its Window. Seems to be 100% unusable right now.

I asked the same question in Alpha and Beta. We were asked to provide a profile trace to show the issue, we did so and then BIS staff never looked at it or did anything with it. Its been the problem with the game since the beginning of Alpha, while at times things improved a little its been messed up for most of the time and never acceptable levels of performance. BIS have been given the full details of the traces in multiplayer showing the issue and have had them for over a year. Its inexcusable at this point for performance to have continuously got worse over time, considering it has been the number 1 issue since the beginning of alpha.

Wars would be a lot more dangerous if everyone was as accurate as the AI in A3. They can shoot an unscoped weapon, standing up to 600-700m and hit the head of the target on the first shot. Those are skills well beyond a human, shots at 100m standing are difficult enough, headshots at 700m standing is impossible but completely common in A3. The AI when turned down via mods is a lot more fun, and you can at least make it match the players capabilities which is lower range and less accurate.

I notice performance is extremely poor in the single player campaign as well, the start of the second mission gets down to 25 fps for me. There are also moments when its all fine and 50fps or so but lots of moments when its unacceptably low, regardless of GPU settings. Same problem as in multi player, game just can't be played regardless of hardware.

If Arma 3 actually split its world render up across 4 cores it would knock about 16ms of main thread time down to about 4ms. That would take the FPS from hovering around 30 to 60. On a 6 core it would go even higher. The game is purely CPU limited, and about half and half between interaction with DirectX (draw call overhead perhaps?) and the world updates. I don't think we'll ever see BIS fix it, they never managed to with A2 so I have no expectations it will ever be fixed with A3. This time however hardware isn't going to save them, we aren't getting more single threaded performance from additional CPUs, so it will just always be slow.

My machine specs: 3930k @ 4.3 Ghz 16 GB DXDR3 2133 2x GTX 680's m4 SSD Benq XL2411T 144 hz monitor The basic performance metrics I know about this system: Altis airport (at our starting location) - 80-90 fps in all directions GPU usage around 75%. Pythos town NE corner - 70-80 fps - GPU usage 60% Pythos town with 40 AI in the town - 45-60 fps - GPU usage 55% Multiplayer with 35 players and 70 AI before the fight - 50 fps - GPU usage 50% Multiplayer with 35 players, 70AI most of them dead - 25fps - GPU usage 30% Multiplayer with 35 players, 70 AI most dead and running a deletion script to remove them - 35-40 fps - GPU usage 40% Singleplayer campaign first mission at start - 25-30 fps - GPU usage around 30-35% Showcase infantry at start - 70 fps - GPU usage 75% Bare in mind during our multiplayer sessions our server FPS runs between 40 and 48 fps, we don't believe server FPS is an issue with so few players and AI. Our tested limit for our server to maintain 40 is 150 AI and 50 players. So I am pretty confident that performance is entirely CPU dominated on the client, at least once you have sufficient GPU performance. It wouldn't make any difference if I went to 3x 780 ti graphics cards, my frame rate would be identical by the looks of things. I see no difference running the game on low settings for example, just lower GPU usage (as measured by GPU-Z). The big problem is the multiplayer performance which I really needed to get to well above 30, ideally more like 60 fps. So initially what I did was create a multiplayer performance mission with 50 v 50 AI battle in a valley and watched from a vantage point. I tested it with our mods, no mods or map scripts +mods and with our full setup including MCC spawned units. I wanted to make sure our modset wasn't to blame. What I determined was less than a 2% difference between the runs, so the scripts+mods didn't seem to be the cause. FPS did drop once the firefight started and map modifications did elongate the performance drop but it also elongated the firefight as well by reducing the AI accuracy but the drop in performance wasn't any worse than the others. In all cases FPS never fully returned after the firefight once they were all dead and stopped moving, but it did recover about 50% of the performance. I saw 80fps before the firefight, dropped progressively to a minimum of 45 during the fight and then recovered to 60 fps. As a test showed the problem to some extent but it never got down to 25 FPS despite all that was missing was 30 odd other players. I tried changing the test in various ways and I couldn't reproduce the 25 FPS, the results didn't really change too much with more or less AI or vehicles or changing the location to a town. This suggested to me maybe it was due to the players and not the AI or the mission. However the performance test did show that dead bodies consumed a lot of performance, so we tried deletion dead bodies mid mission and it certainly helped a bit (as you can see above) but its only about 60% of the drop that happens after a firefight is finished. Whatever is dropping performance through missions is mostly dead bodies, and our best guess is probably PhysX (since it doesn't seem to run on the GPU at all) but there is still a third that never comes back. So create a firefight with 100 AI or so, they all die and then I delete the corpses and the live ones remaining. Even if the firefight and the AI caused a drop in the FPS we would expect once they were removed the FPS would return to what it was before they even existed. There should be nothing consuming CPU or GPU performance left from the firefight and yet that isn't the case. You will get about 60% of the FPS drop back but it will never return. If you now do another firefight of a similar size it will drop even further than it did the first time and deleting it all wont return to the previous levels either. This leaves me with one of two conclusions - there is something in the engine that over time is just dropping performance after stuff happens (because just sitting on the map doesn't show constant drops), or something else is being left behind after a firefight that has quite a dramatic impact on performance. The conclusion is I can't reproduce it outside of our multiplayer game. I can achieve similar FPS in the singleplayer campaign but the cause there is possibly different. One thing BIS could do to improve performance is focus on that single player campaign initial mission with an excess of GPU performance and you can reproduce reliably a low FPS on your own for profiling and fix it. Fixing that will almost certainly translate into real FPS in multiplayer as well, its the only scenario with a single player that has similar FPS that I have found but I don't know if its related to the multiplayer performance issues. For Multiplayer what I think we need is some performance stats logged out (via a switch or whatever) telling us where the time is going on the CPU. Then we can provide results back to the devs to further refine the logging in the area where the problem manifests and over a couple of iterations we should get down to what is causing the problem and the devs know what section of code is going slow and produce reliable tests that show the problem. The alternative is if a dev with a client and a profiler would like to join our weekly game and capture some data and see it for themselves we can organise that (Sunday 20:15 CET). Unfortunately our communities conclusions is that there is no hardware you can buy today that can fix it, client FPS is limited to below the playable threshold on the fastest most expensive CPUs today when overclocked to their maximum. In order for the game to run reasonable on more moderate hardware the CPU time per frame needs to halve so that a more moderate 2.5 Ghz quad core can achieve 30 fps (they get 15 fps today). Tell us how we can help you find the cause. We have quite a few developers in our community so we know how to use profilers and such, just let us know how we can help and fix this.

I have made a short program that can summarise the profiler output and sort the main contributors to performance. The beginning of the mission the top 20 elements on the main thread are as follows: total times=1 totalTime=16.42797 wSimu times=1 totalTime=16.35929 rendr times=1 totalTime=11.55092 hudDr times=1 totalTime=5.0409 oPrep times=1 totalTime=1.67009 wDraw times=1 totalTime=1.50756 wPrep times=1 totalTime=1.50044 wSimA times=1 totalTime=1.46107 recCB times=16 totalTime=1.36057 wsSet times=1 totalTime=1.33 preLd times=1 totalTime=1.24929 pdDrw times=2 totalTime=1.02054 sceAC times=1 totalTime=0.94528 o1Drw times=6 totalTime=0.8402000000000001 wSimR times=1 totalTime=0.77905 sceACPrx times=1 totalTime=0.77576 wSimSV times=1 totalTime=0.72938 xim times=41 totalTime=0.7221199999999993 ximO times=8 totalTime=0.71714 simSo times=5 totalTime=0.66273 The rest of that summary can be found here: http://pastebin.com/W1iQgMvL By the end of the mission that top 20 looks like the following: total times=1 totalTime=35.5624 wSimu times=1 totalTime=35.48974 rendr times=1 totalTime=21.06408 hudDr times=1 totalTime=11.28658 wSimA times=1 totalTime=5.84862 wSimSV times=4 totalTime=4.25627 xim times=168 totalTime=3.7769000000000026 ximO times=111 totalTime=3.750509999999998 wSimO times=1 totalTime=3.0589 sound times=1 totalTime=2.77545 simSo times=30 totalTime=2.5965800000000008 wSimM times=30 totalTime=2.5632399999999995 wDraw times=1 totalTime=2.50926 preLd times=1 totalTime=2.50432 wPSnd times=1 totalTime=2.48584 oPrep times=1 totalTime=2.2682 wPrep times=1 totalTime=2.12109 recCB times=15 totalTime=2.07396 preLV times=1 totalTime=1.57556 o1Drw times=5 totalTime=1.5229300000000001 The rest of this summary can be found here: http://pastebin.com/zG11qptS The total more than doubles,the first trace is ~ 60 fps and by the end of the mission we are at 28 fps. Most elements increase from 1.5x - 2x across the board. Notable call outs however in what changes more dramatically: wSimA grows enormously wSimSV grows enormously xim grows enormously ximO grows enormously These leave the top 20 in the second trace wsSet drops off pdDrw drops off sceAC drops out wSimR drops off sceACPrx drops off simSo drops off And these all grew to take the place of those that dropped out: wSimO 3.0589 sound 2.77545 wSimM 2.5632399999999995 wDraw 2.50926 wPSnd 2.48584 oPrep 2.2682 preLV 1.57556 What strikes me about this summary view of the best and worst traces is that there are clear big gainers responsible for most of the time but its also across a lot of aspects that performance is dropping, from sound, rendering and the simulation itself. Mostly its about 1.5x but there are some things that grew more than 5x as the mission went on. I hope this summary picture where I have summed up all the things with the same name and counted the entries by thread helps you understand what is going on, I personally found it more enlightening than the raw output. If you want access to the code just contact me directly (Dwarden knows how to reach me via Skype for example) and I can provide you details.

All the profiles I have taken show our mod scripts running serially inside of the main thread, they don't seem to run separately. Its somewhat mixed in with the other simulation logic. None of the scripts we are running seem to be massive in time but they aren't run in a separate thread or anything like that, its all on the main thread.

We started complaining in Alpha, it was universal that people were unhappy with the performance of the game and it was CPU limited. The devs did a few tweaks, mostly to the GPU rendering and fixed the problem for lower end GPU users and that was basically it. I seem to remember texture quality took a dive during this process as well (LOD change I suspect). Now we keep providing profiles to show the problem as requested, because the claim is that performance is complicated. Yet every trace I have shows the exact same thing, every game ends up with the same performance problem and its just coop infantry battles with 20 humans verses 50 AI. Its trivial to reproduce poor FPS in this game. I provided a set of profiles traces 3 weeks ago after a dev and community manager requested it but I can't get an acknowledgement its received. Its one thing to have the problem, its a whole other thing to constantly ignore it and hope it goes away. 8 months of fingers in the ears and the customers are getting pretty annoyed. Until its fixed the bad publicity is going to continue, its simply not acceptable to have a game unable to achieve better than about 15 fps in a completely normal and moderate multiplayer game. Its not good enough, period, no excuses.

If you just run the game world updates in parallel with the rendering then you increase the latency from input from the mouse and from other users by an entire frame. You might not think you will notice but you will, its well above the threshold of noticable. The way some console games worked this out was to reduce the impact as much as possible by taking input as late as possible and doing a variety of latency hiding techniques, all of which require significant rewrites of the simulation engine code. There is no way around it, that game world update code needs to go parallel, cheap tricks aren't going to cut it.

Its not like Arma could just move to another engine and be done. No other game has the same size worlds as Arma 3, the AI sophistication, the scripting and modding capabilities. That is all part of BI's custom engine and its what makes the series unique and I doubt any other engine out there could even remotely cope with what they do. Having been asked to profile our game and provide traces to the developers I can fairly confidently say the game seems to be dominated by two aspects, all of which are CPU limitations and seem to be at the core of the games poor performance. 1) The simulation game world updates take a long time. For whatever reason the game world updates frame to frame can take well above 15ms, which if the game were targeting 60fps would be 2/3's of the CPU time per frame just for that activity. That is enormous and the bigger the game the bigger that grows, it also seems to grow with time as well so even if the frame rate starts good once a game has been running for a while it starts to pull the frame rate ever low. The simulation is also entirely single threaded and it only runs in the main thread before the rendering to DX. Thus despite being large and essential before rendering the single threaded nature of the updates means it takes enough time to cause severe performance problems. For the game to achieve 80 fps or so this would need to drop to 1-2ms maximum, instead of the sometimes up to 25ms it takes today. The second big part is the DirectX calls. This seems to take about 10-15ms depending on where you are and what you are looking at. Looking into the island (even if you can't see all that much) takes more time suggesting some part of this must be view distance culling. The game is likely running up against the draw call limits of DirectX as well based on the times and the number of calls I see in the profile. Even though its using multiple threads to some extent its still a high amount of CPU time on the main thread. The combination of the two can put a frame time (in the 35 player games I play) in and around 40ms, or 25 fps. CPU usage total will be around 30%, most of which is the NVidia driver and some of which is the extra threads in Arma, mostly the mjob threads which aid the main thread in the render activity. I think the only route forward from here is that BI needs to put significant work into making the engine parallel, both in terms of rendering and especially into the simulation aspect. Without it the game complexity can't ever grow. Personally I think the simulation time needs to halve right now so the game can run at >30 fps on an extreme computer. Its pretty bad to literally have a game unplayable on a 3930k that is running at 4.4Ghz, you can't get a great deal faster than that. About a year ago BI did publish an article about multiple worlds parallelism (headless client was the start of that) and that was meant to be the future. Honestly I think its not enough. With 8 cores coming out next year with Haswell-E and then Intel's Knightsbridge bringing 40+ low performance cores the day is coming when a single thread will be useless. Its already pretty bad to limit the game to 1/4 - 1/3 of the machines CPU performance and then also be CPU limited as well. Its worse when multiple cores have been out for more than a decade and still your game is basically single threaded. Core investment in really changing their simulation and rendering backend is required at this point and if the situation doesn't change soon they may find Arma 4 isn't even possible and certainly doesn't sell. The target should be 60 fps, period. Right now it seems the target was 15 fps, and that isn't acceptable.

The CPU is what is holding you back. Arma 3 in multiplayer and in the single player campaign is completely CPU limited once you have enough GPU performance to get about 25-35 fps. A much faster CPU than yours still can't maintain 30 fps and the ingame profiler clearly shows the game is dominated by the CPU time. So right now I suspect your quite weak CPU is what is limiting your frame rate. But just keep in mind that there is no CPU out there on the planet when watercooled and clocked to 4.5Ghz that can run the game at 30 fps all the time. Its the game, its kind of broken performance wise has been for months.

Did a similar assault with 14 people to towns to the NE of altis, this time using the new performance binary. Frame rate in the middle of the game dropped down to 30 fps. Thus the performance binary makes no difference to the performance of the game. Our problem is not server side and the recent work there hasn't helped. Profiles from previous page are still the best indication of the performance we are seeing. Dr. Hladik do let me know if you need any other tests doing, otherwise hoping to hear from you soon on what is going wrong to drag the game FPS consistently low.

Arma 3 is a much better game but with 35 players we are struggling with client side performance. Its limited by the CPU and there isn't a whole lot we can seem to do about it. Its not scripts or anything else, its just a real mission as it goes on has reducing FPS (client side). After an hour it'll be down to 25 fps or below depending on your CPU, some of our moderate CPUs are more like 15 fps. The Graphics card is barely used. Arma is still playable at 25 fps (just), but its far from a great experience. We did last week get the diag_captureFrame profiling enabled and the devs now have traces made from real games so hopefully they can work out what is causing the problem and get the FPS fixed. But right now performance is pretty poor and will decline as a game goes on. That doesn't mean its completely unplayable of course, its still a lot of fun and we have been playing arma 3 since the first day of Alpha, its just not as smooth FPS wise as it needs to be and there is nothing you can do about it. If you are playing small missions with like 10 guys you'll probably be OK, but 15 and onwards with 50+ AI is going to start to become a problem and 35 player games are a big issue.

If you turn up the visibility so you can see the whole map then chances are, based on the traces I took, the game is struggling to make enough draw calls and is CPU limited in its main thread resulting in the FPS drop. However if you don't turn up the visibility and instead run it at something reasonable like 2000 and play a real multiplayer game what you find is FPS still drops to 25 fps, and it seems to do so because the simulation of the game world itself is taking a huge amount of time, not particularly because of draw calls. On that main thread are calls out to Input, PhysX, AI, Sound, visualUA, rendering and the game world. With nothing in the world the rendering part takes at least 10ms from anywhere on Altis, more often its 16ms and my traces show it up to 22ms or more. So its very hard for the game to exceed 60 fps just due to the render calls on the main thread. But when you start putting AI and such into the game then game world updates take over as the dominate problem. The issue is its not one thing growing, its basically everything as far as I can see but with the game world updates being the biggest climber throughout the mission. It keeps getting worse despite the AI dying off, the last trace is just us surrounded by dead bodies in a town, with depleted players and everything else. What is taking the simulation so long in those circumstances? Because its got considerably less to do than at mission start which had AI moving around, players moving around etc etc. At the top level lots of the game sim elements grow between my traces, the growth is in basically all the top elements of game world updates, but the names are too cryptic to work out what they mean and do. And because so much shares the main thread the offloaded AI, the doubling of the time processing sound and extra render calls all push it into unplayable FPS. Its not as simple as to say its geometry, so while its true if you have the visibility so high the problem I am looking into is wider than that. I can live with lower visibility settings but we do need a real game (15 players is not a big MP mission) to have playable frame rates.

In these profiles how would the scripts manifest themselves? Its not clear from the cryptic names which aspects our scripts are potentially impacting. From this output it appears that the simulation part of the game is struggling most in the town, what contributes to that and what can we do about it exactly? Are scripts perhaps getting accounted into that and in which aspect? Outside of the town however the game seems to be struggling on the render aspect, it climbs from 16ms to 22ms. Thus it looks like there are too many draw calls occurring there in the open ground and thus responsible for the poor performance. In general the render time is always hovering around 16+ ms so is right at the edge of what is possible, is there an excessive amount of draw calls occurring? Not quite sure what it all means yet, but I don't see one thing, I see a few things that clearly grow in size in a real game, with the simulation aspect of the main thread being the primary concern.

As requested we rerun a mission with extremely poor FPS (CPU limited) with the development branch using the diag_captureFrame. I took note of the server FPS throughout the game and never saw it below 47. Client side FPS started at 77 and dropped to about 55 once the mission was loaded and then by the time we were in range of the enemy FPS was down to 30. GPU usage was low throughout the mission, dropped at the end (when FPS was worst) to 30% according to GPU-Z. Pathagia mission - 15 players(!) in multiplayer - around 100 AI with 4 light vehicles (2xtrucks, 2xifrits) most in and around the town. Some static assets like 50cals, tow and most AI in static fortified positions. Traces taken at various points through the mission for comparison: (1) - All players connected, no AI or other mission assets: http://pastebin.com/p9VgvNdm (2) - AI loaded but players still at main airport: http://pastebin.com/LvvqGFYG (3)- Players down 1KM southwest of objective town moving in: http://pastebin.com/tC3aZYGP - Points taken through the mission as we enter the town and fight through: (4) http://pastebin.com/3xZD4L3G (5) http://pastebin.com/GQvvHgjF (6) http://pastebin.com/N5bQvKwh (7) http://pastebin.com/yXRiKLWw - Mission completed, nothing but dead bodies around in the town: (8) http://pastebin.com/aPnACFDH Also earlier in the day I captured the following with the mission load, just me in ghost amoung the AI, should tell us what the players are costing us in comparison to trace 4: http://pastebin.com/xkaBteJj Let us know if you need any more information. I will start taking a look through all the traces myself and try to summarise what grows in time consumption as the mission progresses.

The dev branch has the profiler in it, so switch to it and destroy a load of buildings and record the FPS and profile before and after. That well tell you if it is a problem (some numbers would be good) and tell the developers why its going wrong (via the profile).

In the Editor, single player character placed NW of Pythos looking South at this moment is 55 fps and the following trace as of todays dev branch (07/12/13) 17:30 CET: http://pastebin.com/Hehvc0J8 Adding 80 AI only marginally decreases FPS in the same location and direct to 50 fps at this moment, AI has no behaviour added, just added 20 standard fireteam groups produces the following trace: http://pastebin.com/ARdt00x6 I would love to capture the multiplayer scenarios, alas I can't get the community I am in to change to development for this purpose. I need a stable compatible build with profiling in built. The current development branch version wont connect to our game server so I can't profile those multiplayer games, but I am happy to if you can get me a stable compatible build with diag_captureFrame in it, just let me know how to get it. Just as a check I also did the airfield check looking towards the terminal where I typically get 77 fps and I am getting 55 fps as well: http://pastebin.com/wLY52AL8 So the profiling is having a significant impact on the baseline performance and obscuring the difference between the two scenarios, I suspect there are very few places I can get better than 60 fps on that build of code. So its only worth looking into the very low FPS scenarios like with the multiplayer scenarios so for that unfortunately I need a profiling stable build.

When I run Koplic alongside our modset I see 12 errors of the following type, one after the other, in the RPT. These seem to be unique to the Koplic mod, I don't get them on Stratis or Wamako. a3\structures_f\households\wip\unfinished_building_02_f.p3d: house, config class missing The other notable difference in the RPT is that Wamako has a CBA log output with some details that is not present on Koplic. [473228,5812.98,0,"XEH: PreInit Started. v1.0.4.198. MISSINIT: missionName=wamako_intro, worldName=sfp_wamako, isMultiplayer=false, isServer=true, isDedicated=false"] [473228,5813.09,0,"XEH: PreInit Finished. CACHE DISABLED? (Disable caching with cba_cache_disable.pbo): SLX_XEH_RECOMPILE=false, CBA_COMPILE_RECOMPILE=false, CBA_FUNC_RECOMPILE=false"] Not sure if that helps but its a couple of places to start.

Do you have any clue why there is a problem with CBA? We would love to use the map but since we run ACRE in our community we are dependent on having CBA present in our mod list, not just for ACRE but for other mods as well. I appreciate you are busy with the map but it would be nice to get to the bottom of the conflict between the two mods and either raise a bug on CBA or fix the problem within the map at some point as your going to find a lot of communities can't run it until the problem is resolved. For now we have tested and had to decide not to add the mod, this conflict means it isn't really usable in its current form. BC Admin Tier1Ops.eu

I didn't originally have a problem on the first release of the game, it ran well. Then my motherboard failed and I rebuilt around a different motherboard, a new patch come out and I went back to Windows 7 having previously used Windows 8. Between those three changes my FPS on very high has gone from mid 70's to high 20s low 30s at the same settings. So initially I didn't have this problem, my 3930k@4.4 and 2x680s ran the game very well and now it runs it very poorly and not a whole lot has changed. The machine itself runs other games just as well as it did before. There is no performance problem in Crysis 3, Far Cry, BF3 etc etc. 3D mark shows the performance is almost identical, its almost the same hardware so no surprises there. The very noticeable difference for Arma 3 between the two setups is that GPU usage has dropped from around 70% per card (140% in all, so some SLI scaling) to a miserable 30% per card (60% of one card). So there is no point having two cards and not even a single 680 is being used. I can't explain why the same hardware is producing dramatically different results, either its the move from an Asus motherboard to the Asrock or its the patch that was released or Windows 8. Windows sounds very unlikely and the hardware is running great otherwise so I think it was the patch, but its very strange and deeply annoying. Its kind of destroyed my enjoyment of the game, I have had to drop the graphics enormously to get it playable and now I have a game that doesn't look much better than Arma 2 and still doesn't really run very well.

With a pair of 680's if I don't overclock my 3930k at all then its hard to even get one card fully used let alone 2. Without overclocking it is extremely difficult to get to 60 fps in a real game let alone the 120Hz I would like to have. As others have said it seems almost entirely limited by the CPU performance, and that seems to be dominated by the object view distance setting. Decreasing view distance dramatically improves performance. One thing I did note however was that setting the game into AFR mode 2 improved frame rates about 20% compared to the default, it seemed to increase the utilisation of the second card. It only has an impact when the machine is overclocked however, it seems to make no difference with the CPU at default clocks.

Tier 1 Ops is seeing 2 full cores worth of utilisation once the server is full, and with a decent amount of AI. However I have some unconfirmed reports saying it can benefit (even if its only a little) from 6 cores which I would like confirmed if possible. So far the 2 core utilisation is pretty reliable, its never gone above it at any point. Server slots and the amount of AI are entirely dependent on the performance of those 2 cores basically. We saw the same thing in Arma 2, 1-2 cores of utilisation. Arma 3 at least is more consistent about using 2 cores, Arma 2 really only used 1 and sometimes more occasionally, due to our modset, peaking to 3 cores for brief moments.