fred41

@kelemenlajos, this is already planned. I will add this soon ... ---------- Post added at 18:54 ---------- Previous post was at 18:50 ---------- @dwarden, thanks for your report. This is an old bug, which occure if your arma server terminates abnormal (crashes) and DLL_PROCESS_DETACH isn't called. I think this should be fixable ... ---------- Post added at 20:35 ---------- Previous post was at 18:54 ---------- UPDATE: 06.12.2013: simple log feature added (-lfilenameprefix, -tinterval) This logfile(s) will be generated in ASMs workdirectory and are written each interval seconds (default 1). There is no header in this files, the fields are delimited by a '|'. The order of values is the following: TimeStamp|FPS|CPS|PL#|AIL|AIR Enjoy :)

"SeIncreaseWorkingSetPrivilege" grant the right to set the minimum/maximum workingsetsize for a users process. AFAIK, this privileg is granted per default for the whole "users" group. However, it has no impact to the allocation of large pages, because large pages are not part of process "workingset" (large pages are not pageable). Btw: The term "workingset" is used with different meanings, in different tools, this could be a bit confusing.

... i tried with performance monitor now and got 7-8000 PF/s average, much more as process explorer told me (1-3000). Not sure what tool tell us the truth ... I think the source for that soft pagefaults, is the frequently mapping/transfering (via MapViewOfFile) of small (64kB) areas, from this big "addressless" system memory area (~ 1.6GB) to arma process address space.

... let me know how many RAM your system has? And does it work each time direct past fresh restart? ... not yet, but if i found the time, i will add a log feature and let you know ...

... i see something like 1-3.000 per second, but i use a custom memory allocator, with most pages locked to phys. RAM. I will compare with default allocator later, 60.000/s seems to be a bit to much.

... 6 million per 5 minutes (300sec), are 20.000 per second and this means 20 faults per ms (average) ... Lets hope this are soft page faults, because hard page faults means i/o reads writes occure. But soft page faults, even if very much faster (page transition, in memory), they need cpu resources too. Are there other applications running in the background while you observe this?

... only miracles around tbbmalloc :D @ramius, there is a way to make gpedit available for 7 home premium too, but maybe "page lock privileg" is default enabled here or other applications set it already ... @NoPOW, hmmm ... looks like everything is working well with LP allocation on your system. And still no difference in performance? Who know, maybe an other bottleneck is here in the foreground ...

UPDATE: ASM now records up to 24h (86400 seconds) to RAM (ringbuffer). History is now scrollable (+/- time offset) via LMB. Time offset reset to zero via double click. Timedivisor selectable via popupmenu as usual.

... ok, what value is shown by task manager "memory (private workingset)" for your arma 3 process, if arma is running with tbbmalloc?

... this starts to be interesting ;) It seems VMMAP shows bullshit, and it works probably perfect for you, large pages included. Do you really use VMMAP 3.11, the latest, because there is NO "total working set" shown in this block:confused:

... very nice idea ... just imagine a multiplayer speed boad race around stratis ^^ Good luck, cant wait to try this out, when ready :)

... it means, tbbmalloc allocates and uses the memory in small pages (instead of large). Check the following: Did you set the page lock privilege as described for the arma user? Do you have enough physical RAM? Did you tried a fresh system start and start arma immediately afterwards? (If your system RAM is heavy fragmented (long running), it is possible that your OS has not enough 2MB regions left and tbbmalloc is forced to fall back to small pages or to terminate immediately.) I will add a log file output to the next version for easier analysing such problems. New version will appear soon. Greets, Fred41

... assuming you use VMMAP 3.11, it should look like this: "Process:" "arma3.exe" "PID:" "3884" "Address" "Type" "Size" "Committed" "Private" "Total WS" "Private WS" "Shareable WS" "Shared WS" "Locked WS" "Blocks" "Protection" "Details" ............. "80000000" "Private Data" "2.048.000" "2.048.000" "2.048.000" "2.048.000" "2.048.000" "" "" "2.048.000" "1" "Read/Write" "" ........ ... if not, it seems LP allocation failed for some reasons.

... yes, i share your concern and i found the following: If your user account, which you use to start arma, is in the Administrator group, then you have to start arma as administrator too. If your user account, which you use to start arma, is a normal account, then you can start arma normally (not as administrator). This seems a bit confusing, but it works this way, just now tested. In any case, the user account, which you use to start arma, must have the privilege to lock pages in memory (see last posts). Greets, Fred41

@Lordprimate, i think i fully understand your confusion, so let me try to exlain (still in pure english): The advantage of large pages, is a significant performance boost for all memory accesses to the related areas. The disadvantage is, that it could be difficult on systems with less physical RAM, to find free areas for allocation, because of higher allocation granularity. Ok, now to your question: To use some large pages for arma (via tbbmalloc), the user account/group which you use to start arma (client or server) must have: 1. the privilege, to lock pages in memory 2. if your arma start user is in the administrator group, then you have to start arma as administrator To ensure the 1. condition you have to do exactly, what is described in your link: http://msdn.microsoft.com/en-us/library/ms190730.aspx (adding your account, not removing him). I am assuming, you know how to ensure condition 2. And don't forget to restart your system. To verify your success, you could use the methode, i described in my last post. I hope it works and let us know your results, Fred41

... yes exactly this, big thanks ramius :) @Lordprimate, it is very likely, that you don't grabbed the latest, because this would terminate, if lock pages privileges aren't properly set (the latest version was only one day on git). You could use the following tool, to verify if large pages are used: http://technet.microsoft.com/en-us/sysinternals/dd535533.aspx Start vmmap while arma is running and select the arma process. If you scroll down a bit, there should be a big memory block of 2,048,000K shown, in column "Locked WS" (yellow). Greets, Fred41

... it's not only "ok", i am really more than happy, that someone is brave enough and able, to interface with this stuff at lowest level :) I will publish the source of the ASMdll.dll on github soon, maybe you can use some of this code for your project too. BTW: Your screenshot looks very promising :) Greets, Fred41 --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- EDIT: Source of ASMdll.dll published on github (just a few lines). Everybody is free to use it, maybe as start for own projects or just as example, how to use callExtension in a simple and fast way.

... this. Just have to add an important point for script execution in the VM (scheduled environment): We have to know, that each command invoked by the script interpreter (even in VM), is blocking script execution up to command return. Because of that, we have to take care, that commands invoked by the script interpreter DON'T need to much time. For example: Commands like nearObjects, combined with large radius parameter or callExtension, can easily extend a frame to the length of many ms (if not seconds). But i think we will read more about that in the (hopefully) upcoming performance blog :)

... there is already a very long queue for OS's, ASM should support, but at first place is IOS, because my son requested it months ago for his iPod :D

... when leaving arma and before reboot, did you check if arma process is still running (taskmanager -> processes) ?

... oh, checked the wrong executable. Just now checked the right one (OA latest beta) and the LAA flags are set. Ok, in this case, tbbmalloc.dll (especially preallocation of nearly 2GB memory, above 2GB address space) could/should basically work on A2/OA too. Thanks for your hint and sorry for that incorrect information, Fred41

... that s exactly what i think too. It probably needs individual investigation for each mission, to find out if some objects are accumulated over time or even not. Even if cleanup script itself needs resources too, increasing the frequence of cleanup execution, can help to minimize the additional load from dead objects. This perhaps sounds contradictory, but it is a working way to increase overall performance, because the cleanup script is running in the VM and will not impact the servers FPS.

@ramius, thanks for testing. I think on server a difference will be more shown under heavy load (50+ player, much script processing, event handler), but it is only asssumtion by me. @Neodammerung, i have checked the A2/OA executables, there is no LAA flag set (like in A3), therefore memory addresses above 2GB are not available for arma process. This means tbbmalloc.dll will not really work with A2 currently, sorry :/ Thanks for test and reporting. Greets, Fred41

... hi, and thanks for report ... @ramius, under what load (player numbers, mission, duration) did you test server side? @Neodammerung, what bugs did you observed serverside in A2? What conditions are your server running, when bugs occur (player numbers, mission, duration)? Greets, Fred41

Related to cleanup: I think it would make always sense, to verify the success of fresh implemented cleanup. A simple way is the use of count allMissionObjects "All" at mission start and periodical while mission is running (lets say each 5 minutes). If the number of objects is significantly increases with time, then we have to find out, what kind of objects are accumulated here and to include this objects in our cleanup too. BTW: This object counting is one of the optional features provided by Arma Server Monitor, exactly for the main purpose of cleanup verification