fred41

@JumpingHubert, a large pages page is nothing else then an countinous block of 512 small pages. The degree of fragmentation in your physical RAM (contamination of large pages with small pages), depends of the memory activity of all running processes on your system and of system uptime. So if you have a clear system and a lot of RAM, fragmentation is not really a problem and you should not see much performance decrease over time. So the best way to have a stable performance is to keep your system as clean as possible, or you have to restart more often. The mallocxxxx.log file in your a3 root directory is a good help to analyse fragmentation (LP=large pages, SP=small pages). As long as there are no 'fallbacks' to SP, everything is well.

... inbox cleared, let us continue there ...

Try restart your arma server instance, while ASM is already running. Start a mission on arma server instance. Let me know.

Yes, such fallbacks to SP (small pages), are indicating heavy fragmented physical RAM. AFAIK the only way to restore from such state is a restart (at least in current windows versions). To delay or prevent fragmentation, some attention is required, to maintain a clear system. Background processes like windows search service, background virus scanner e.t.c, can massive accelerate memory fragmentation and should be disabled for maximal availability of large pages and performance. (See tbbmalloc thread for more details and tips: http://forums.bistudio.com/showthread.php?163640-Arma3-and-the-LARGEADDRESSAWARE-flag-%28memory-allocation-gt-2GB%29) @matt_gold, in github repository use the 'RAW' button for binary download of GMF.exe tool.

@Cyruz, are you running your server as service? If yes, you have to start ArmaServerMonitor via 'Run as administrator' to get the required access to a shared memory region.

@KillSwitch, you explained it perfectly and i have nothing to add (maybe except, that the returned value have to be a positive number). Many thanks :)

@oldy41, i think a better solution for you could be, to create a normal (not a member of admin group) account and running arma from this. This solution is more secure and probably work better with your other software too.

Try to isolate the source of the problem systematical. 1. Disable GMF tweak, by merging GMF_off.reg (from github repo) 2. Make a link to arma3.exe on your deskop, adapt the params, including -malloc=tbbmalloc as first parameter 3. Start arma (via desktop link) and verify in your .rpt file, that tbbmalloc is really used as allocator 4. if 3. yes, then there should be a mallocxxx.log file in a3 rootdir 5. post this malloc log file here (we use tbbmalloc just as analysing tool here)

... looks much better now, but ... Look at 34.991s in your malloc.log file, there is your OS out of large pages. This means your memory is fragmented. This is most likly caused by this: system physical RAM total: 8067 system physical RAM available: 5784 As you can see there are ~2.3GB of your 8GB already used at arma start. You should find out, what consumes that much RAM and free it if possible. You can still use maxmem=2047, without any problems.

@TonyGrant, thanks for correcting me, i didn't see the '.dll' was wrong ---------- Post added at 16:38 ---------- Previous post was at 16:33 ---------- @Inch, @VanZant, @St.Jimmy, &nomisum, thanks for testing and feedback! I think, it is good to know, that the best things in live are still free :) ---------- Post added at 16:44 ---------- Previous post was at 16:38 ---------- Please understand that i can't support tbbmalloc in detail here too. This would result in additional confusion and i think we have already enough here. http://forums.bistudio.com/showthread.php?163640-Arma3-and-the-LARGEADDRESSAWARE-flag-%28memory-allocation-gt-2GB%29 ---------- Post added at 16:49 ---------- Previous post was at 16:44 ---------- @Nikiforos, indeed, this would be great. At least as easy to use option. So let us see.

@Abuser, your logfile shows, the required privileg is not enabled. If you run your arma with an account that is member of the administrator group, then you have to start arma/steam via 'Run as administrator' too. Additional you should check, what is using so much of your 8GB physical RAM and free as much memory as possible for arma. EDIT: sorry, i probably didn't read your post correctly. One more question, did you run 'AddLockMemoryPrivilege root' in a console with admin rights? If nothing of the above helps, you can use the manual methode, using secpol.msc. Don't forget a restart.

... no and no ... ;)

The second registry key in wow6432node branch, is a automatically generated copy and don't have to be changed manually. Did you try to start arma and/or steam, via 'run as administrator'?

Related to your attempt to use tbbmalloc: The first thing i see in your arma launch command line is, that -malloc=tbbmalloc.dll is nearly at the end. My experience is, that the -malloc param only works as one of the first parameters. So better put at first position and than look in your .rpt file if tbbmalloc is really used. If you have more tbbmalloc related questions, please ask in the related thread. Now back to topic. To have any advantage from GMF tweak, two conditions must be met: The 'lock pages in memory' privilege have to be set for the useraccount which you use to run arma. (additional: if this account is member of the administrator group, you have to start arma via 'run as administrator' too) This can be done via secpol.msc manually, but can be done with my little tool GimmeMoarFrames.exe too. The second condition is that, a registry key and a DWORD value are created and set correctly. This can be done, ether with registry editor or with my little tool too. See initial post for more details. In any case, if something doesnt work as expected, you just have to make one of the changes reverse and everything is like before. ---------- Post added at 19:33 ---------- Previous post was at 19:29 ---------- ... this is a very good idea, but i think it is not a good idea to spoil peoples to much ... ;)

I didn't tested it, but i see no reason that it should not. Please test it and let us know. (if it doesnt work you have to set the registry value 'UseLargePages' back to 0 manuelly via registry editor, see initial post for keyname)

@St. Jimmy, tbbmalloc related questions should be better asked in the related thread (see servers & administration), but i will make an exeption :) Since you probably already set the required privilege (for GMF tweak), all you have to do now, is downloading tbbmalloc.dll from my github repo (folder binary) and install it in a3\dll folder. Then add '-malloc=tbbmalloc' as first parameter in your arma launch command line. Check your mallocxxxx.log file to verify that everything is working. If you are unsure, post your .log file in the related thread and i will take a look.

Can someone else please test the 'GimmiMoarFrames' registry/privilege tweak for arma3server.exe on a server 2012/2012R2 system, without the CFF patch? Thanks in advance, Fred41

Inch, many thanks, very good explained, and really a big help for me :) ---------- Post added at 20:25 ---------- Previous post was at 20:22 ---------- @nohrt, thanks. Good news are always welcome :) ---------- Post added at 20:29 ---------- Previous post was at 20:25 ---------- Correct. (Or just merge 'GimmeMoarFrames.reg' from github repository :p ---------- Post added at 20:37 ---------- Previous post was at 20:29 ---------- ... pah, benchmarks and numbers ... What counts is the experience to master it :p

... i really know such situations well ... However, it could be a bug in pre 2012 windows versions. The CFF patch relates to VS linker option 'Randomized base address' and it seems to be incompatible with 'UseLargePages' for image file loading, at least in windows 7. So MS probably fixed this incompatibility with 2012 windows versions. Will add this hint to usage instructions for 'GimmeMoarFrames'. Thanks for sharing.

The only thing that is changed by this tweak is, that arma3.exe is 'mapped' in a, so called, large page memory region. The result is, that the CPU has less to wait to load code and data from memory that is not in caches. Thats all. I hope i could answer your question. ---------- Post added at 20:08 ---------- Previous post was at 20:03 ---------- ... hmmm, i don't have access to a 2012R2 system (nor that much cores :)), but i really don't see a reason for such strange behavoir. When i have an idea later, i will let you know. ---------- Post added at 20:11 ---------- Previous post was at 20:08 ---------- ... thanks, but i wouldn't say this that harsh ;)

... it works great for me ... I explicitly wrote it in the hardliner section, because it requires a bit experience to make it running. It especially requires carefully reading before trying ;)

... this is a very good question ... I think the easiest way is to make 2 .reg files and merge it on demand. GMFOn.reg : GMFOff.reg : @Das Attorney, your results are interesting, but i am not shure if they are expected. You will only see a speedup, if enough large pages are available on your system to map the arma3.exe imagefile in a large page region. You have only 6GB RAM and if your system is not very clean your memory will go fragmented fast. Try a restart before you run your bench. The more experienced user could use a tool like VMMAP (sysinternals) to verify, that the arma3.exe imagefile is really mapped to a large page region. Greets, Fred41

I have some (very individual) numbers, if this increase your guys motivation to test it. i5/2500k/4GHz 16GB/1600Mhz/9-9-9-24 win7/64bit Viewdistance 1600, textures high, e.t.c. 'Helos A3 Benchmark' (modified to get 0.1FPS resolution, loaded and saved in editor for each new arma build) each test with 3 averaged runs/results, arma fully restarted for each test results:avg/max 73.5/74.2 vanilla 78.1/79.3 GMF 82.1/84.1 GMF + tbbmalloc (LP) Don't blame me if you get other numbers, this can have many reasons. Greets, Fred41

Everything is still well with tbbmalloc. I only meant the registry tweak, for additional performance. Meanwhile, i found a solution to use this tweak for arma3server.exe too. If you guys are interested, see readme.md in github repo (hardliner section) for more details. The only problem is that this patch is overwritten with each steam update (needs to be fixed by BIS for a permanent solution). Greets, Fred41

Unfortunately i realized to late, that arma3server.exe doesnt work correctly, if mapped in a large page region. I am really sorry for the trouble caused, by my (over) excitement about the new discovery :rolleyes: For everybody, this tweak currently only works for client and HC. Greets, Fred41