fred41

(view/objdist 1600/1105 low/standard) 1.32/1.34/1.36RC2 (default allocator, w/o GMF tweak): ~74.5/~69.5/~79.5fps 1.32/1.34/1.36RC2 (tbbmalloc, with GMF tweak) ~84.0/~79.0/~89.5fps in other words: 1.36RC2 looks really promising (while 1.34 was a shoot in the ...) ------------------------------------------------------------------------------------------------------------- minor LPManager update uploaded: recycle algo optimized

... what kind network services? Hint: Watch the workingset sizes of all running processes (process explorer).

@bolbies, you should have enough free physical RAM and a 64bit OS, to have a positive effect with this allocator. Which OS, how much physical RAM (total/free) do you have? Pagefile size?

@root, thanks for your series of measurements. I got broadly similar results. I think the improvements are better comparable expressed in relative (percentual relation of fps), instead of absolute (fps difference). (multiplayer improvements are already planned, i am just still waiting to get access to arma's whole source code :bounce3: ) minor LPManager update: added a checkBox 'DisablePagingExecutive' 'DisablePagingExecutive' is an registry value, that controls wether kernel memory is pageble (allowed to swap to pagefile) or not. For systems with enough physical RAM, it is generally recommendet to disable kernel paging for better system performance. In respect to availability of large pages, disabling kernel memory paging, has a very positiv effect (at least on my system). You can now easily set/unset this value via checkBox in LPManager (a restart is still required).

@Azer1234, nothing has changed, except LPManager ... Just download the latest version of this tool (github, via RAW button). ---------- Post added at 19:32 ---------- Previous post was at 19:27 ---------- @root, yep looks good. Maybe, you can cleanup your system a bit (disable background processes, that are not really needed). (my system works great with only ~40 processes, your has ~80 running :p ) BTW: have you tried benchmarking, with and without 'GMF' tweak too?

... a little update for LPManager again: The new 'Clear Mem' feature, requires two additional privileges, which obviously are not set per default on every systems accounts (thx dwarden for hint). This are namely: 'Adjust memory quotas for a process' and 'Profile single process'. As usually, you can add this two privileges ether via secpol.msc OR by reusing the 'Privilege' button in LPManager (with your useraccountname in editor field, LPManager must 'run as administator' started). (to use this new features, you have to download the latest LPManager from github) If you don't need the 'Clear Mem' feature, you dont need this two additional privileges and the 'Clear Mem' button will just be disabled in LPManager.

... hmm, at least a restart should restore a significantly higher ammount of unfragmented physical RAM on your system. What is a 'memory block cleanup' btw? ---------- Post added at 16:06 ---------- Previous post was at 16:01 ---------- It's all over town, isn't it? ;) BTW: A 64 bit build will provide a linear address space of nearly 8TB for each process, instead of 4GB, as suggested in your signature:) ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- minor LPManager update: Added a button 'ClearMem'. Try this button, if reported 'physical RAM LP avail.:' value is low, to 'defragment' some of your physical RAM. Internally, it reduces systems filecache workingset, clears standbylists etc. This cleanup process may need some seconds, verify the success of cleanup by comparing the values before and after.

... there is a minor update for the tool LPManager ... LPManager is now able to 'measure' the availability of large pages (continous 2MB blocks in physical RAM), diplayed as: 'physical RAM LP avail.:'. Press 'Info Update' button to update this value. Additional there is a new button 'ClearMem' for clearing RAM and restoring some of the fragmented physical RAM (experimental). (Don't use this two buttons (or only with care), while arma is running, because it will temporary allocates alot of your physical RAM) LPManager is now build as true 64bit application for two resons: 1. to overcome the 4GB limit, while counting the large pages on systems with lots of RAM 2. to be better prepared for the upcoming 64bit builds of arma 3 °° Greets, Fred41

... a good suggestion for a conventional HDD, but a bad one for a SSD ;)

Assuming you have a 64bit windows OS and enough free physical RAM (8GB+), 'tbbmalloc for arma' should work for other BI games, which are using the same interface, too (Arma 3/2, DayZ ...). The 'GMF' tweak should basically works for many applications, not only games. The expected performance gain depends of some factors. Generally, applications with large executable binarys, will bennefit most from large page mapping. ---------- Post added at 20:32 ---------- Previous post was at 20:30 ---------- Do you have some more details (your OS, ammount of physical RAM, error messages)?

@Nikiforos, i have to confirm your observations, there is obviously a (new) serious performance problem, introduced with the latest stable update. I use 'Helos Altis Benchmark' too and got the following numbers: 1.32/1.34 (default allocator, w/o GMF tweak): ~74.5/~69.5fps 1.32/1.34 (tbbmalloc, with GMF tweak) ~84.0/~79.0fps With 1.32, this benchmark was running mostly smooth with my settings. With 1.34 it is notificable stuttering. Thanks for your effort, to reporting and making a ticket for this issue. Greets, Fred41

@ToejaM, this behavoir could be be related to a known API monitoring issue (NTI value), that may occure, if clients are still connected at server shutdown/restart. Try 'enableAPImonitoring=0' in asm.ini, to disable this feature completly. @SGTGunner, UI design/implementation is not really my strong side ... ... but, you can disable all unwanted graphs by RMB over history area and uncheck in the popup menu. Did you try the 'bold mode' for vertical stretching (-b commandline switch)? For more details/options see the readme.md description in asm github repository. Greets, Fred41

@Boozfob, i would suggest to use this one in 'binary' folder. ('safer_deref' comes from an attempt to fix an earlier issue, occured with servers in dev branch and is a bit slower because of additional checking)

@deltagods, this sounds like a .dll name conflict. Probably an other application trys to use this specialized .dll. Just terminate all arma sessions, rename the 'tbbmalloc.dll' to 'tbbmalloc_fa.dll' and use '-malloc=tbbmalloc_fa'. This should solve the conflict, please let me know.

@CosmiC10R, thanks for your reply. Nice numbers, is it with or without GMF-tweak? Yep, arma seems to be 'confused', if core params like -malloc or -cpucount are at later positions in the command line.

@pegruder, i forgot to mention, that you dont need the '-mod=@ASM', because autostart doesn't work for A2. Just copy the 'ASMdll.dll' in A2 root, pack 'fn_asm.fsm' in your mission (rootfolder) and use this line: if (isServer) then { ["MyProfileName"] execFSM "fn_ASM.fsm" }; in missions 'init.sqf' to launch the 'fn_ASM.fsm' at mission start. (you have to do this for each mission you want to monitor on your A2 server) ASM starts to monitor at mission start, not at arma start. @Cyruz, thanks for helping out. Modifying the .fsm is no longer nessecary for A2, since the last update. You can/must now define your prefered profilename in the param-array for .fsm. Greets, Fred41

... yes, i would, because the usage of large pages have some performance related advantages over small pages. (see earlier hints about minimal requirements and how to avoid memory fragmentation)

@pegruder, ASM is using some features not available in A2, for example the 'preinit' autostart methode doesn't work for A2. But there is a way, to use ASM in A2 too, by 'manually' start 'fn_asm.fsm' from init.sqf in your mission (see my post from Jul 4 2014).

@Tonci87, yes, obviously you did everything right. (You are running Vista 64 bit, without any service pack?) Anyway, you can clean up your system from unnecessary background processes and improve the availability of large pages this way. Please read a few posts earlier, for additional hints.

@Tonic87, for the GMF tweak, presented here, you only have to look at the initial post of this thread for detailed usage instructions ('LPManager' is the easy way). The custom memory allocator 'tbbmalloc for arma' is independent of this GMF tweak, but you can use it additionally, if you like. Infos about 'tbbmalloc for arma' can you find here: http://forums.bistudio.com/showthread.php?163640-Arma3-and-the-LARGEADDRESSAWARE-flag-%28memory-allocation-gt-2GB%29 Greets, Fred41

@Jertzukka, the normal way to grant the 'SeLockMemoryPrivilege' is, using 'secpol.msc' and adding a user/group to this privilege. Did you try this already? The easy way to grant this privilege, is via 'LPManager.exe', which will show you, if the privilege set operation was successfull ('Restart' in green letters means success). In any case a system restart is required once!!! Additional, consider the following: If the user, which you use to run arma is member of the administrator-group, then you have to start arma via 'run as admin'!. I hope i could help.

Ok guys, thanks for your answers. Based on your replys i found the following: 1. 'GPU_DetectedFramesAhead' is still modified by arma, even with '-noBenchmark' 2. without any load, 'GPU_DetectedFramesAhead' is always set to 1 on my system, with vsync=ON/OFF 3. with heavy load (synthetical loop in onEachFrame event) arma sets it to 1, if VSYNC is ON and to 2, if VSYNC is OFF CONCLUSION: It is not randomly and seems to have some meaning :)

@ChuWie, nice to read you make progress with clearing your system. 'Windows search service' is such a black sheep too. Just stop and disable it, nobody really need such things (services.msc). On my system, i have only ~40 processes running in background and i don't miss anything :) Additional, i highly recommend to have a look for GMF tweak too, if you don't already use it. Greets, Fred41

... WOW and thanks, this are really good news, time to move to linux :) I will add your link to the initial post of this thread. Greets, Fred41

@mizifih, thanks for your log. The first thing, that needs attention, is this: 'SeLockMemoryPrivilege: denied, huge pages disabled' what means the privilege, required for large page mapping, is not set correctly. Additional, i think your system could be cleared up a bit, by unloading some applications/services (see some hints, a few posts earlier).