Arma3 and the /LARGEADDRESSAWARE flag (memory allocation > 2GB)

[spanishsurfer 58]

Fred, saw this on the EUTW forums: http://eutw.net/forums/viewtopic.php?f=23&t=1471&p=7267#p7267

Players are reporting inability to connect to servers and they're blaming your .dll as the culprit. I use it and play on those servers with no problems so I'm not sure what's going on there.

[z13l5ch31b3 10]

Hi Fred,

it figured out that your malloc causes Arma3 crashes.

I could play with it (and the registry tweak) for about 3 weeks, but since monday, it continously crashes while loading the mission (on the last fifth of the loading bar; CTI TeaTimes mission) and gives me a BattleEye: corrupted data #3 error (BattleRoyale).

After using the tbb4malloc_bi it works without any issues. Maybe you have to check this out.

Cheers

/edit: and me (or others) won't 'blame' you or your work. You did a good one, but something's wrong with it. And i dont think it's about blaming to report this.

Fred, saw this on the EUTW forums: http://eutw.net/forums/viewtopic.php?f=23&t=1471&p=7267#p7267

I use it and play on those servers with no problems so I'm not sure what's going on there.

Lots of players got the issue that they 're unable to connect. An admin advised me to check Fred's stuff. I love his stuff btw. And changing the allocator fixed it instantly.

Edited June 18, 2014 by z13l5ch31b3

[Greenfist 1863]

@z13l5ch31b3: I had the issue until recently. Almost every server kicked me after a minute of playing with the same BE error. It only occurred when I used Steam server browser. Gamespy worked fine. The same thing with default and custom allocator.

Someone recommended updating BE manually and verifying game files to fix the problem. I didn't get to try because I reinstalled Windows which cured it. Haven't experienced it since then, with or without tbbmalloc.

Of course, since the BE error is quite generic, my issue may be complete unrelated to yours but try updating Battleye manually anyway.

[z13l5ch31b3 10]

@z13l5ch31b3: I had the issue until recently. Almost every server kicked me after a minute of playing with the same BE error. It only occurred when I used Steam server browser. Gamespy worked fine. The same thing with default and custom allocator.

Someone recommended updating BE manually and verifying game files to fix the problem. I didn't get to try because I reinstalled Windows which cured it. Haven't experienced it since then, with or without tbbmalloc.

Of course, since the BE error is quite generic, my issue may be complete unrelated to yours but try updating Battleye manually anyway.

Thanks for the tip, and maybe others need it. For me, switching the malloc solved the problem.

[fred41 42]

Thanks everybody for reporting this.

Honestly, i dont think that the use of large pages via tbbmalloc nor image file mapping in large page region can cause such behavoir directly.

But who knows, i will try to reproduce this and let you know.

Greets,

Fred41

EDIT:

Loading a 4MB mission, no problems. Tested around 1 hour (as player :)) no problems too (all test in stable branch only).

Everybody getting such problems as described above, please check if you have enough physical RAM available to run arma with tbbmalloc (8GB).

Because large pages are not pageable and are always mapped in real RAM, you need a bit more RAM!

Try setting/increasing pagefile size, if not already done.

Edited June 18, 2014 by Fred41

[ecid 10]

[...]

But who knows, i will try to reproduce this and let you know.

[...]

Just to give you an example of scale fred41,

we are running 5 servers at EUTW.NET, with 10-ish missions on rotation.

It was not localized to any server nor any specific Map, but rather random. A player having the issue on #3, could have it on #2, while not having it on #4. while others had it on #1 and #5, but not on #2,#3, #4. And all combinations of the above server numbers working/not working)

27 players reported the issue to me alone on TS.

After a lot of investigating (which included restarting the PC, not starting any software, and checking ram with memtest86+, plus others) it turned out that out of those 27, 23 had the following in common: your memory allocator.

After removing it (including the gimmemoarFrames fix (if present)) those 23 could connect to the servers, they had issues on, again.

The issue did not pop up again.

I have updated our forum entry to clearly state, the info you provided with regards to 8GB of Ram needed. (which is good to know)

Edited June 19, 2014 by Ecid

[fred41 42]

@Ecid, thanks for your detailed feedback.

When i was filtering for 'eutw', i found 2 servers listed: 'EU #1' & 'EU #2'.

I joined both, tbbmalloc (latest stable) active and 'arma3.exe' mapped in large page region (GMF).

Found absolute no problems: while server joining / mission loading, nor while playing (nice mission btw, Teetimes 2.00.21).

So, just let me know, if the problem still exists for your players, since they are following my usage suggestions (64bit, 8GB+).

Greets,

Fred41

[lordprimate 159]

Fred41, our server runs tbb_malloc and so do i. Several people in my community run tbb_Malloc. All of us can join our server and play for hours, no problems, What so Ever...

Good luck in your debugging efforts, but know, that my community is not having ANY issues with tbb_malloc!!

[ecid 10]

@Ecid, thanks for your detailed feedback.

When i was filtering for 'eutw', i found 2 servers listed: 'EU #1' & 'EU #2'.

I joined both, tbbmalloc (latest stable) active and 'arma3.exe' mapped in large page region (GMF)

[...]

(nice mission btw, Teetimes 2.00.21).

.

There should be #1 .. #5 for EU :-) Thanks for the compliments, i'll relay them to the chef.

Back to the issue:

In case i did not make this clear: It did not happen for everyone using your memory allocator. However, for those that had that issue, the memory allocator was the cause.

My bet is, that their issue stemmed from the following:

!(64bit, 8GB+)

fragmentation in physical address space.

(fragmentation means, simple spoken, small page allocations are contaminating/destroying continuous blocks of memory, large pages, over time)

[DaViSFiT 21]

I just reported the same on another thread. We had yesterday the same problem, starting people cant join anymore from 15 players, getting worse with more players. they cant connect to server anymore, waiting in the connect screen forever. Could this really be a problem with this dll? We run a ramdisk with 16GB from 32GB totally ram, -tbmalloc -enableHT -nologs -nosound and perf1. I cant find a solution yet, beside we had problem appearing in ingamebrowser since 1.22.

[fred41 42]

I just reported the same on another thread. We had yesterday the same problem, starting people cant join anymore from 15 players, getting worse with more players. they cant connect to server anymore, waiting in the connect screen forever. Could this really be a problem with this dll? We run a ramdisk with 16GB from 32GB totally ram, -tbmalloc -enableHT -nologs -nosound and perf1. I cant find a solution yet, beside we had problem appearing in ingamebrowser since 1.22.

... hmmm, sounds similiar to the phenomena, described by ecid ...

@Numrollen, do you remember, what exactly has changed on your server, since you observed this problem?

[kremator 1065]

I just reported the same on another thread. We had yesterday the same problem, starting people cant join anymore from 15 players, getting worse with more players. they cant connect to server anymore, waiting in the connect screen forever. Could this really be a problem with this dll? We run a ramdisk with 16GB from 32GB totally ram, -tbmalloc -enableHT -nologs -nosound and perf1. I cant find a solution yet, beside we had problem appearing in ingamebrowser since 1.22.

Surely -malloc=tbbmalloc numrollen ?

[DaViSFiT 21]

Of course -malloc=tbbmalloc, very funny.....

Fred: The only i know was the patch 1.22, perf1 and -enableHT. I really dont know where to start, its frustrating if clan players wants to join but nothing helped. Now i deleted HT stuff and lets see. I will try to reproduce it but our server is mostly active only @ weekend.

[BL1P 35]

Observed around 10% increase in server performance when using this .dll based on the AIServerBenchmark results.

[fred41 42]

Observed around 10% increase in server performance when using this .dll based on the AIServerBenchmark results.

... cool, seems to help especially with AMD CPU's ...

I got only ~4% with my intel i5 and ~9% with additional GMF tweak.

---------- Post added at 13:12 ---------- Previous post was at 12:57 ----------

UPDATE:

I have replaced GMF.exe, with a easy to use GUI tool, LPManager.

Look in folder 'tool' in my repository for LPManager.exe and readme.txt for usage instructions.

This tool simplifies something around the required large page setup for tbbmalloc and for GMF tweak too. Try it out.

Additional, i added a special version of tbbmalloc in folder 'binary_safer_deref'.

Because of slightly decreased performance, please use it only if you got problems, as described by 'ecid' some posts earlier.

This special version will or will not fix this problem. I really don't know, because i still can't reproduce it.

Please report if it helps or not!

[jerminhu 25]

It is very interesting that although I didn't enable large pagefile for my ArmA 3 server in the registry, the tbbamalloc log still says large pages are enabled:

WindowsVersion: 5.2  ServicePack: 2.0  Typ: Server

process virt. address available:  1971
system physical RAM total:        8181
system physical RAM available:    6034
system committed limit:          18224
system committed peak:            7155
system committed current:         3952
system cache current:             2041
system handles:                  218970
system processes:                   67
system threads:                    900

system uptime minutes:              15

SeLockMemoryPrivilege: granted, huge pages enabled

  0.000s: 0.045ms  2048k at:0x7fc00000 Alloc LP (   2M)
  0.000s: 0.005ms   128k at:0x02a70000 Alloc SP (   2M)
  0.016s: 0.167ms 12288k at:0x7e400000 Alloc LP (  14M)
  3.531s: 0.515ms  4096k at:0x7f800000 Alloc LP (  18M)
  3.531s: 0.345ms  4096k at:0x7f200000 Alloc LP (  22M)
  3.531s: 0.338ms  4096k at:0x7e000000 Alloc LP (  26M)
  3.531s: 0.338ms  4096k at:0x7dc00000 Alloc LP (  30M)
  6.391s: 0.507ms  4096k at:0x7d800000 Alloc LP (  34M)
  6.391s: 0.342ms  4096k at:0x7d400000 Alloc LP (  38M)
  6.391s: 0.346ms  4096k at:0x7c400000 Alloc LP (  42M)
  6.391s: 0.340ms  4096k at:0x7c000000 Alloc LP (  46M)
  9.547s: 0.464ms  4096k at:0x7bc00000 Alloc LP (  50M)
  9.547s: 0.340ms  4096k at:0x7b800000 Alloc LP (  54M)
  9.547s: 0.337ms  4096k at:0x7b400000 Alloc LP (  58M)
  9.547s: 0.346ms  4096k at:0x7b000000 Alloc LP (  62M)
 10.141s: 0.535ms  4096k at:0x7ac00000 Alloc LP (  66M)
 10.141s: 0.347ms  4096k at:0x7a800000 Alloc LP (  70M)
 10.141s: 0.417ms  4096k at:0x7a400000 Alloc LP (  74M)
 10.141s: 0.352ms  4096k at:0x7a000000 Alloc LP (  78M)
 11.156s: 0.483ms  4096k at:0x79c00000 Alloc LP (  82M)
 11.156s: 0.358ms  4096k at:0x79800000 Alloc LP (  86M)
 11.156s: 0.353ms  4096k at:0x79400000 Alloc LP (  90M)
 11.156s: 0.352ms  4096k at:0x79000000 Alloc LP (  94M)
 15.375s: 0.510ms  4096k at:0x78c00000 Alloc LP (  98M)
 15.375s: 0.375ms  4096k at:0x78600000 Alloc LP ( 102M)
 15.375s: 0.355ms  4096k at:0x78200000 Alloc LP ( 106M)
 15.375s: 0.357ms  4096k at:0x76400000 Alloc LP ( 110M)
 15.516s: MFCA req.
 16.453s: 0.503ms  4096k at:0x75800000 Alloc LP ( 114M)
 16.469s: 0.368ms  4096k at:0x75400000 Alloc LP ( 118M)
 16.469s: 0.356ms  4096k at:0x75000000 Alloc LP ( 122M)
 16.469s: 0.354ms  4096k at:0x74c00000 Alloc LP ( 126M)
 85.125s: MFCA req.
 85.125s: MFCA req.
 85.125s: MFCA req.
 85.328s: MFCA req.
 85.328s: 0.662ms 18432k at:0x72a00000 Alloc LP ( 144M)
 85.360s: 0.544ms  6144k at:0x73e00000 Alloc LP ( 150M)
 85.391s: 0.568ms  6144k at:0x71e00000 Alloc LP ( 156M)
 85.391s: 0.542ms  6144k at:0x71400000 Alloc LP ( 162M)
 85.735s: 0.163ms  4096k at:0x74600000 Alloc LP ( 166M)
 85.735s: 0.547ms  4096k at:0x72600000 Alloc LP ( 170M)
 85.735s: 0.408ms  4096k at:0x71000000 Alloc LP ( 174M)
 85.735s: 0.409ms  4096k at:0x70c00000 Alloc LP ( 178M)
 85.735s: 0.444ms  6144k at:0x70600000 Alloc LP ( 184M)
 85.735s: 0.144ms  6144k at:0x70600000 Free     ( 178M)
 86.031s: 0.593ms  4096k at:0x70800000 Alloc LP ( 182M)
 86.031s: 0.365ms  4096k at:0x70400000 Alloc LP ( 186M)
 86.047s: 0.423ms  4096k at:0x70000000 Alloc LP ( 190M)
 86.047s: 0.412ms  4096k at:0x6fc00000 Alloc LP ( 194M)
 88.797s: 0.483ms  4096k at:0x6f800000 Alloc LP ( 198M)
 88.797s: 0.350ms  4096k at:0x6f400000 Alloc LP ( 202M)
 88.797s: 0.348ms  4096k at:0x6f000000 Alloc LP ( 206M)
 88.797s: 0.349ms  4096k at:0x6ec00000 Alloc LP ( 210M)
 91.297s: 0.689ms  4096k at:0x6e800000 Alloc LP ( 214M)
 91.297s: 0.559ms  4096k at:0x6e400000 Alloc LP ( 218M)
 91.297s: 0.355ms  4096k at:0x6e000000 Alloc LP ( 222M)
 91.297s: 0.348ms  4096k at:0x6dc00000 Alloc LP ( 226M)
 91.485s: 0.494ms  4096k at:0x6d400000 Alloc LP ( 230M)
 91.485s: 0.356ms  4096k at:0x6d000000 Alloc LP ( 234M)
 91.485s: 0.348ms  4096k at:0x6cc00000 Alloc LP ( 238M)
 91.485s: 0.348ms  4096k at:0x6c800000 Alloc LP ( 242M)
 96.391s: 0.653ms 12288k at:0x6bc00000 Alloc LP ( 254M)
 98.078s: 0.480ms  4096k at:0x6b800000 Alloc LP ( 258M)
 98.078s: 0.358ms  4096k at:0x6b400000 Alloc LP ( 262M)
 98.078s: 0.349ms  4096k at:0x6b000000 Alloc LP ( 266M)
 98.078s: 0.348ms  4096k at:0x6ac00000 Alloc LP ( 270M)
104.141s: 0.589ms 12288k at:0x6a000000 Alloc LP ( 282M)
104.438s: 0.593ms 12288k at:0x68a00000 Alloc LP ( 294M)
104.719s: 0.547ms  4096k at:0x69c00000 Alloc LP ( 298M)
104.719s: 0.359ms  4096k at:0x69800000 Alloc LP ( 302M)
104.719s: 0.355ms  4096k at:0x68600000 Alloc LP ( 306M)
104.719s: 0.399ms  4096k at:0x68200000 Alloc LP ( 310M)
106.375s: 0.542ms  4096k at:0x67c00000 Alloc LP ( 314M)
106.375s: 0.364ms  4096k at:0x67800000 Alloc LP ( 318M)
106.375s: 0.349ms  4096k at:0x67400000 Alloc LP ( 322M)
106.375s: 0.349ms  4096k at:0x67000000 Alloc LP ( 326M)
107.688s: 0.007ms    16k at:0x0a530000 Alloc SP ( 326M)
108.594s: 0.519ms  4096k at:0x66c00000 Alloc LP ( 330M)
108.594s: 0.367ms  4096k at:0x66800000 Alloc LP ( 334M)
108.594s: 0.353ms  4096k at:0x66400000 Alloc LP ( 338M)
108.594s: 0.349ms  4096k at:0x66000000 Alloc LP ( 342M)
110.797s: 0.502ms  4096k at:0x65c00000 Alloc LP ( 346M)
110.797s: 0.361ms  4096k at:0x65800000 Alloc LP ( 350M)
110.797s: 0.351ms  4096k at:0x65400000 Alloc LP ( 354M)
110.797s: 0.350ms  4096k at:0x64e00000 Alloc LP ( 358M)
113.891s: 0.505ms  4096k at:0x64a00000 Alloc LP ( 362M)
113.891s: 0.377ms  4096k at:0x64600000 Alloc LP ( 366M)
113.891s: 0.351ms  4096k at:0x64200000 Alloc LP ( 370M)
113.891s: 0.350ms  4096k at:0x63e00000 Alloc LP ( 374M)
117.281s: 0.522ms  4096k at:0x63a00000 Alloc LP ( 378M)
117.281s: 0.355ms  4096k at:0x63600000 Alloc LP ( 382M)
117.281s: 0.350ms  4096k at:0x63200000 Alloc LP ( 386M)
117.281s: 0.350ms  4096k at:0x62e00000 Alloc LP ( 390M)
120.422s: 0.007ms    16k at:0x0a540000 Alloc SP ( 390M)
125.735s: 0.513ms  4096k at:0x62a00000 Alloc LP ( 394M)
125.735s: 0.369ms  4096k at:0x62600000 Alloc LP ( 398M)
125.735s: 0.352ms  4096k at:0x62200000 Alloc LP ( 402M)
125.735s: 0.350ms  4096k at:0x61e00000 Alloc LP ( 406M)
153.078s: 0.499ms  4096k at:0x61a00000 Alloc LP ( 410M)
153.078s: 0.354ms  4096k at:0x61600000 Alloc LP ( 414M)
153.078s: 0.361ms  4096k at:0x61200000 Alloc LP ( 418M)
153.078s: 0.352ms  4096k at:0x60e00000 Alloc LP ( 422M)
595.985s: 0.590ms 12288k at:0x60200000 Alloc LP ( 434M)
828.219s: 0.495ms  4096k at:0x5fe00000 Alloc LP ( 438M)
828.219s: 0.358ms  4096k at:0x5fa00000 Alloc LP ( 442M)
828.219s: 0.355ms  4096k at:0x5f600000 Alloc LP ( 446M)
828.219s: 0.355ms  4096k at:0x5f200000 Alloc LP ( 450M)
1236.906s: 0.650ms 12288k at:0x5e600000 Alloc LP ( 462M)
1279.578s: 0.006ms    16k at:0x023f0000 Alloc SP ( 462M)
1388.063s: 0.476ms  4096k at:0x5e200000 Alloc LP ( 466M)
1388.063s: 0.414ms  4096k at:0x5de00000 Alloc LP ( 470M)
1388.063s: 0.522ms  4096k at:0x5da00000 Alloc LP ( 474M)
1388.063s: 0.521ms  4096k at:0x5d600000 Alloc LP ( 478M)
1835.610s: 0.553ms  4096k at:0x5d200000 Alloc LP ( 482M)
1835.610s: 0.401ms  4096k at:0x5ce00000 Alloc LP ( 486M)
1835.610s: 0.394ms  4096k at:0x5ca00000 Alloc LP ( 490M)
1835.610s: 0.393ms  4096k at:0x5c600000 Alloc LP ( 494M)
2286.891s: 0.590ms  4096k at:0x5c200000 Alloc LP ( 498M)
2286.891s: 0.406ms  4096k at:0x5be00000 Alloc LP ( 502M)
2286.891s: 0.397ms  4096k at:0x5ba00000 Alloc LP ( 506M)
2286.891s: 0.391ms  4096k at:0x5b600000 Alloc LP ( 510M)
3949.578s: 0.318ms  4096k at:0x5b200000 Alloc LP ( 514M)
3949.578s: 0.536ms  4096k at:0x5ae00000 Alloc LP ( 518M)
3949.578s: 0.407ms  4096k at:0x5aa00000 Alloc LP ( 522M)
3949.578s: 0.394ms  4096k at:0x5a600000 Alloc LP ( 526M)
4759.203s: 0.005ms    16k at:0x02400000 Alloc SP ( 526M)
4762.625s: 0.611ms  4096k at:0x5a200000 Alloc LP ( 530M)
4762.625s: 0.616ms  4096k at:0x59e00000 Alloc LP ( 534M)
4762.625s: 0.591ms  4096k at:0x59a00000 Alloc LP ( 538M)
4762.625s: 0.590ms  4096k at:0x59600000 Alloc LP ( 542M)
6350.735s: 0.565ms  4096k at:0x59200000 Alloc LP ( 546M)
6350.750s: 1.047ms  4096k at:0x58e00000 Alloc LP ( 550M)
6350.750s: 0.975ms  4096k at:0x58a00000 Alloc LP ( 554M)
6350.750s: 1.021ms  4096k at:0x58600000 Alloc LP ( 558M)
7379.828s: 0.327ms  4096k at:0x58200000 Alloc LP ( 562M)
7379.828s: 0.357ms  4096k at:0x57e00000 Alloc LP ( 566M)
7379.828s: 0.407ms  4096k at:0x57a00000 Alloc LP ( 570M)
7379.828s: 1.259ms  4096k at:0x57600000 Alloc LP ( 574M)
9140.547s: 1.187ms  4096k at:0x57200000 Alloc LP ( 578M)
9140.547s: 1.043ms  4096k at:0x56e00000 Alloc LP ( 582M)
9140.547s: 0.896ms  4096k at:0x56a00000 Alloc LP ( 586M)
9140.547s: 1.164ms  4096k at:0x56600000 Alloc LP ( 590M)
12707.438s: 0.616ms  4096k at:0x56200000 Alloc LP ( 594M)
12707.438s: 1.024ms  4096k at:0x55e00000 Alloc LP ( 598M)
12707.438s: 0.987ms  4096k at:0x55a00000 Alloc LP ( 602M)
12707.438s: 0.905ms  4096k at:0x55600000 Alloc LP ( 606M)

However, I don't see any FPS increase. And I'm using latest PERF binary.

Do I need to enable it and test again?

Edited June 28, 2014 by jerminhu

[fred41 42]

It is very interesting that although I didn't enable large pagefile for my ArmA 3 server in the registry, the tbbamalloc log still says large pages are enabled:

... you are running windows server 2003 - 32bit (64bit is highly recommended)?

If tbbmallocxxxx.log says:

SeLockMemoryPrivilege: granted, huge pages enabled

this means, that the windows useraccount, that is used to start arma, is allowed to lock memory pages (SeLockMemoryPrivilege).

You can enable/disable this privilege via poledit or secpol.msc (if available), for each useraccount/group.

(see readme.md in tbbmalloc's github repository, for more details)

But what do you mean with: 'I didn't enable large pagefile'?

[jerminhu 25]

I meant that the registry key UseLargePages in entry [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\arma3server.exe] is currently set to 0.

I have too many programs running on this server that I can't afford to do a complete reinstall.

So according to the log, my server has correctly enabled tbbmalloc and large pages and I don't have to change the registry value? I ask this because I failed to see any FPS increase.

And I'm wondering why I am not getting startup crash when using tbbmalloc on the server.

Edited June 28, 2014 by jerminhu

[byohzrd 10]

I have replaced GMF.exe, with a easy to use GUI tool, LPManager.

I'm attempting to run this tool on Win Server 2012 R2 and I'm being told "This app can't run on your PC". Any thoughts?

[fred41 42]

I meant that the registry key UseLargePages in entry [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\arma3server.exe] is currently set to 0.

I have too many programs running on this server that I can't afford to do a complete reinstall.

So according to the log, my server has correctly enabled tbbmalloc and large pages and I don't have to change the registry value? I ask this because I failed to see any FPS increase.

And I'm wondering why I am not getting startup crash when using tbbmalloc on the server.

... ah, you are mixing tbbmalloc and 'GimmeMoarFrames' tweak ...

The GMF tweak is a registry tweak, that requests windows, to map the arma3(server).exe in a large page region.

The GMF tweak requires the same privilege 'SeLockMemoryPrivilege' to be allowed to use large pages.

This tweak doesn't work with arma3server.exe on windows 7 (crashes at start) and the only way to fix this is a patch of arma3server.exe binary (see GMF thread, for details).

I don't know how it works on windows server 2003, did you try?

How do you measure FPS on your server (arma server will always run at 50 FPS without load)?

---------- Post added at 17:53 ---------- Previous post was at 17:52 ----------

I'm attempting to run this tool on Win Server 2012 R2 and I'm being told "This app can't run on your PC". Any thoughts?

... yes, use the 'RAW' button, to download this file via github (and don't forget to read the readme.txt :)).

[jerminhu 25]

I measure the FPS with your server monitor. It's about 48 without load. But the FPS reporting tool in a3wasteland reports 5 fps lower.

How do I check if mapping a3 image file to large page memory region is working?

I've changed the value of the registry key for arma3server.exe to 1 and restarted the server. The server still started without crash. But the FPS is still the same.

Edited June 28, 2014 by jerminhu

[fred41 42]

I measure the FPS with your server monitor. It's about 48 without load. But the FPS reporting tool in a3wasteland reports 5 fps lower.

How do I check if mapping a3 image file to large page memory region is working?

I've changed the value of the registry key for arma3server.exe to 1 and restarted the server. The server still started without crash. But the FPS is still the same.

You can use VMMAP (sysinternals), to check if arma3server.exe is mapped, using large pages. If it is in a large page region, then the size of the region, where arma3server.exe is mapped, must be a exact multiple of 2MB.

Comparing FPS on a running server is difficult, because FPS is dynamic under load.

Meanwhile i use BL1P's nice AIServerBenchmark mission, to measure the difference between different settings.

http://forums.bistudio.com/showthread.php?179341-BL1Ps-BenchMark-fun

AFAIK, this is currently the only way to easy compare server performance.

[DaViSFiT 21]

Are there any news about the "cant join" problem? I dont use the tbbmalloc on our public server atm, im unsure about all the problems we had :)

[doclee 10]

Hi guys,

Really sorry to parachute here but my game always crashes with a TBBMALLOC error (in the RPT file), I dowloaded your version but still get the same freeze and crash issue. Memory and system are ok (I tested them) so is there no other issue than to upgrade (motherboard, proc and OS)?

I've asked in many forums but no one seems to have an answer for me. any thought?

Specs:

Vista 32 bits

ASUS P5Q pro

Intel 2 quad Q9400 2,66ghz

4Go

GTX 760

Thank you very much.

Edited July 13, 2014 by doclee

[fred41 42]

Are there any news about the "cant join" problem? I dont use the tbbmalloc on our public server atm, im unsure about all the problems we had :)

...are you aware of the little update (see post #415, for details)? This is just a 'blind fly' attempt only, because this 'cant join' issue is not reproducable for me.

---------- Post added at 14:58 ---------- Previous post was at 14:52 ----------

Hi doclee,

please read the description of this allocator.

Your system is not 64bit nor it has enough physical RAM (win64/+8GB recommended).

You could try the GMF tweak only, to get some percent better performance (it only needs 24MB large page memory).

Greets,

Fred41