fred41

initial post updated, with info about manual methode (for mor experienced users) @Brainbug & RuairiAU, i basically share your concerns @vegeta897, use the 'RAW' button in github to download the 'GimmeMoarFrames.exe' binary file

@bravo409, with only 3GB system memory? I don't think that this will really work, sorry.

Hi, nothing of both. This is the windows useraccount name, the name of the account, which you use to start arma (supports client only currently).

... sorry, guys for the confusion, i will try to make things clear. This registry tweak works additional to the usage of tbbmalloc with large pages. So, if you already set the required privilege correctly, you only need the registry tweak to map arma3.exe in large page region too. If you don't set this privilege already, you have to do it now. The easiest way to do this, is with my new 'all in one' tool 'GimmeMoarFrames.exe' (see readme.md in repo for details) Greets, Fred41 EDIT: I just now see, that my arma3server.exe makes problems too, will investigate this tomorow. If someone runs in trouble with server too, just set the UseLargePages value back to 0, for arma3server.exe registry key (registry editor). I have disabled the tweak for arma3server.exe temporarily, seems to work fine with arma client.

... i am not absolutly sure, you could set the 'lock pages in memory' privilege as described and give it a new try ... But generally i think, it is time for an upgrade. Sorry, it hurts to say that. ---------- Post added at 20:50 ---------- Previous post was at 19:10 ---------- UPDATE: added a little tool for easiest usage (see initial post for details)

@GiorgyGR, it depends on the amount of physical RAM in your system (without any relation to the reg. tweak presented here). @bravo409, it doesn't matter where the file is located, you just merge it and the data are in your registry, thats all @Greenfist, move to 64bit OS and upgrade to at least 8GB, ASAP :) @JumpingHubert, never trust statistics, which you didn't manipulated by yourself ;) !!!!!! Guys, sorry, i forgot to mention that the 'lock pages in memory' privileg have to be set for large page availability, will update initial post accordingly !!!!! So, if you don't use 'tbbmalloc for arma' already successfully, you have to pay attention to this privilege now.

@JumpingHubert, don't believe him, he's joking as usual :) (but at least there is a real difference)

... indeed, should have similar effect as in a3 ... https://github.com/fred41/GimmeMoarFrames (just repeated this link for the blind guys :) )

BTW: Did you know, that mapping a3 image file to large page memory region, significantly accelerate execution performance? Look for 'GimmeMoreFrames' in my github repository, for a very simple, but powerful registry tweak. https://github.com/fred41/GimmeMoarFrames Up now, try it out :)

@nics, ok and thanks for clarification. (I just now found, that pthread_key_create() is the unix equivalent of TLSAlloc() in windows and this is indeed essential for tbbmalloc to work.)

@tomeek, arma2 doesn't support the preinit function, introduced with arma 3. As viba wrote, it requires explicit starting. On way is packing the fn_ASM.fsm file in your mission and call it from init.qf via a line like this: if (isServer) then {[] execFSM "fn_ASM.fsm";}; @Viba, thanks :)

@nics, nice to meet you here and thanks for all your work, to make arma server running on linux.

... and which of the 320 post's you mean exactly?

... i see, you aren't joking :)

... thanks k0rd, for sharing this info. If i understand it correctly, LD_PRELOAD works basically with arma server, so that Nics solution fixes the mallinfo() problem very efficient. But other bugs in arma server, are preventing a succesfull replacement of malloc functions via LD_PRELOAD, so that preloading tbbmalloc, for example, don't work. Nics did a great job, by locating this heavy bugs and it should be a lot easier for BIS devs now, to fix it finally and permanently.

@patxitron, wow, very smart °°. Do you think, it would be possible, to make intels tbbmalloc available for arma server on linux, using the same chroot aproach? (http://www.gnu.org/software/libc/manual/html_node/Hooks-for-Malloc.html) Greets, Fred41

@patxitron, very interesting appoach at all. Thats linux, nothing is impossible (i am currently reading the LFS book, awesome stuff :) )

ArmaServerMonitor.exe should run on all current windows versions. Probably your downloaded file is damaged. Please use the 'RAW' button in github to download the file again. Greets, Fred41

@patxitron, instead of a zeroed structure, your proxy function could return a saved structure from low frequently mallinfo() calls. pseudo code: { if ((count++ % 1024) == 0) saved_mallinfo_struct = mallinfo(); return saved_mallinfo_struct; }

... i think, as long, as your system has always enough large pages available (no fallback to SP, ^^ malloc####.log), there should no paging to disc occure too, and it makes still sense to use the left RAM for accelerating your slow IO ... ---------- Post added at 16:04 ---------- Previous post was at 15:06 ---------- Added a probably useful, little tool here: https://github.com/fred41/tbbmalloc_arma/blob/master/tool/AddLockMemoryPrivilege.exe This tool should be helpful, to set the SeLockMemoryPrivilege on systems, where secpol.msc is not available. Usage (cmd.exe 'Run as Administrator'): AddLockMemoryPrivilege armauseraccountname (Tested with windows 7 only) Greets, Fred41

UPDATE: fixed, monitoring NTI/NTO values should work now with A2, if you set enableAPImonitoring=2 in asm.ini (thanks Viba, for reporting and testing) (for A3, please use still enableAPImonitoring=1) Greets, Fred41

... assuming you are familiar with the manual start methode of fn_ASM.fsm and you are using the latest build, API values like NTI, NTO and DIR should be available on arma 2 too? (i didn't tested with arma 2 and it is possible that A2 uses other API functions then A3)

Hi Terox, i am really not an expert for all this network related params, but maybe i can help to interprete values showed by ASM. First of all, i think the goal of all optimizations is still: improving the experience for the players. This in mind, we have to consider, that ASM can tell you only what happens in your server process directly. At least the latest development progress suggests, that BI developers decouple servers and client cycles more and more, so the feedback of your users will be more and more important too, to evaluate the success of network parameters tuning. However, i think maximizing the servers FPS makes still sense, because it is still very important, that our server is able to react fast to all events that have to be processed. FPS vs. CPS Servers FPS is a value, that tells us how many whole simulation cycles per second are processed and this includes all the non scheduled script processing in your mission. Non scheduled means, it have to be processed, what ever happens, in the current cycle and serial (one by one). So if there are many scripted eventhandlers, for example, this will extend your simulation cycle and FPS goes down. Scheduled execution, on the other hand, is much more 'relaxed'. Technically it is a time frame of ~3ms per simulation cycle, where this script code is allowed to be processed. This scheduled execution is done in the VM and many scripts can be processed in (pseudo) parallel. Additional there is a (linear) relation between condition evaluations in FSM and VM load observable. CPS stands for 'condition evaluations per second' and means how often a condition in FSMs can be evaluated. It mainly impacts AI reaction performance. We could say, low CPS is mostly caused be a overloaded VM. We can also observe, that CPS is never above FPS, but can be much lower indeed. In any case, CPS should not be impacted directly by network parameters, but by mission design/scripting. I hope i could help a bit, at least to understand CPS/FPS better. Directly related to network parameters: If i see the many, many questions around this important values and i realize how much time it needs to evaluate each little modification, i really start to ask me, why not making this parameters tunable in real time? I mean a simple monitoring/tuning interface (via UDP socket or shared memory), just moving one of some sliders on server and asking the players via chat "is it better now?". :) Greets, Fred41

.... nice find, thanks ... :)