"3FPS Issue" - Call for Help

[alexbu 6]

1 hour ago, dwarden said:

 

since 1.66 it's not recommended to use -maxmem= nor -maxVRAM= at all (the engine auto-detect and tries use maximum available)

it's now only fall-back for 'troubleshooting` or non-standard problematic hardware situations ...

 

Hey @dwarden (and all) some players and I already talked of this bug HERE

And we found out that use "-maxmem=2047" completely solved the problem. No crash anymore in most of the case

[Chewz 23]

I doubt this information has any relevance to this issue, by the sounds of things players are getting this on SP as well as MP, if that is the case this post is completely irrelevant but I thought I might as well throw in my input while I'm here

 

From my own personal experience with both ArmA 2 OA and more recently ArmA 3 over the past 6 months, I noticed an increase in players complaining about this so-call 3fps bug, however, I've always been able to find a solution. The following information from ArmA 2 is from the past 4 months, and the information provided about ArmA 3 is from the past month or so.

 

On an ArmA 2 server I ran, with approximately 50 people on we received about 50-75% of our players complaining about their FPS, I notably enabled some additional battlEye filters a few hours before hand due to an increase in hacker attacks we'd be having; after this change we started getting complaints. I waited a few days, restarted the server on a regular basis and modified our basic.cfg settings to try and optimise our bandwidth usage so I could try and figure out if the issue was client side or server side. After a few days I disabled all battlEye filters and refreshed the battlEye events & scripts logging and to my surprise, it fixed this issue. My players simply had to restart their game and rejoin, and it completely fixed their issue.

 

To confirm it was battlEye, I got the staff team of the community I worked for onto the development server (~20 people), enabled some useless BattlEye filters that would somewhat simulate a major player base running the regular BattlEye filters, and to my surprise, they got this 3fps issue within about 10 minutes, if not less.

 

I had a similar experience with a recent ArmA 3 server I'd setup; we were running a generic Lakeside Life Server on Tonic's mission; I added some additional battlEye filters to counter the extra modifications to the mission (both mods and code), and after these changes we're initially made, I, as the only person on the server at the time (it was a Development server) noticed after about 10 minutes I would receive this 3fps issue for about 2 minutes before my game crashed due to, if I recall correctly an 'out of memory' error.

 

After some extensive testing, I was having similar issues as the original author; requiring a game restart to fix the issue, or even the game just crashing after a set amount of time. Furthermore, the time generally ranged from as low as 10 minutes all the way up to an hour.

 

If I can make an initial recommendation to any server owners with players suffering from this issue; try disabling your most network (and client) intensive battlEye filters (such as scripts.txt and remoteexec.txt) if not all of them, Obviously do this without notifying your players and keep them disabled for a hours if you can (unless its a private server) and see if your players who commonly complain about this FPS issue keep on getting it. If you don't actually have any battlEye filters (I don't know why private milsim units would require battlEye filters), then I'm unsure at this point what might be causing it

EDIT:

 

Before APEX was released, I worked for an ArmA 3 community that ran an average ArmA 3 Life server, they never received this issue before the release of APEX, but after the release of APEX and they changed their battlEye filters to meet the new requirements, they kept receiving reports of this 3fps issue. They had no clue what was causing it and at the time I didn't know how to fix it, it was only in August when I vouched to assist an ArmA 2 server due to their recent increase in hacker attacks & lack of developers that I noticed this FPS issue really started to occur. It never happened before I added new BattlEye filters, it happened as soon as I added in new battlEye filters and then stopped when I removed them + the players unfortunate enough to receive this issue restarted their games.

 

Just another side note to do with APEX & its slightly off topic, but I've noticed since APEX's a large percentage of players with relatively good internet kept getting kicked for 'Signature Check Timed Out'. Even though many of the players get 60fps+ and have an average ping ranging from 10 to 50. They've ensured that their game files are up to date (some players even went to the extent of reinstalling Windows completely), which to my surprise didn't fix this issue.

 

The box I used to run the server is:

> Intel Xeon E5-1620 @ 3.6GHz

> 32gb RAM

 

CPU maxes out at 20% (without HC) and about 4GB RAM (w/o HC)

 

 

 

Further edit:

 

On 03/02/2017 at 1:56 AM, i3eefy said:

Hi Ladies and Gents

 

I can play arma between 30 - 40 min before a massive FPS drop and then black screen. I have to go into the task manager and end the task to get out of it. So here is one of the error's i got out of the .rpt file

 

 0:38:00 DX11 error : CreateTexture failed : E_OUTOFMEMORY
 0:38:00 Virtual memory total 4095 MiB (4294836224 B)
 0:38:00 Virtual memory free 303 MiB (318050304 B)
 0:38:00 Physical memory free 8545 MiB (8960262144 B)
 0:38:00 Page file free 18656 MiB (19562356736 B)
 0:38:00 Process working set 2962 MiB (3106267136 B)
 0:38:00 Process page file used 3431 MiB (3598442496 B)
 0:38:00 DX11 error : CreateTexture failed : E_OUTOFMEMORY
 0:38:00 Longest free VM region: 9240576 B
 0:38:00 VM busy 3993878528 B (reserved 155910144 B, committed 3837968384 B, mapped 148217856 B), free 300957696 B
 0:38:00 Small mapped regions: 34, size 143360 B
ErrorMessage: Out of memory (requested 15529 KB).
  footprint 2379816960 KB.
  pages 131072 KB.

 

And here is another one

 

23:43:25 Virtual memory total 4095 MiB (4294836224 B)
23:43:25 Virtual memory free 335 MiB (352313344 B)
23:43:25 Physical memory free 8100 MiB (8493957120 B)
23:43:25 Page file free 18888 MiB (19805749248 B)
23:43:25 Process working set 2946 MiB (3089674240 B)
23:43:25 Process page file used 3386 MiB (3550838784 B)
23:43:25 Longest free VM region: 13172736 B
23:43:25 VM busy 3960127488 B (reserved 156782592 B, committed 3803344896 B, mapped 161103872 B), free 334708736 B
23:43:25 Small mapped regions: 36, size 151552 B
ErrorMessage: Out of memory (requested 15219 KB).
  footprint 2373984256 KB.
  pages 131072 KB.

 

Both are very similar and I am lost as to what to do next. After reading I'll try the maxMem and report back

 

 

If I recall correctly, I got the exact same error spammed in the logs as soon as I received the FPS issue, details wise, I know this isn't really much info, but, it could be BattlEye? who knows 

[DerZade 73]

I'm having this issue especially since the last update. I can confirm, that the game sometimes recovers this can happens after a couple of seconds but I also had some occurrences where it did recover after 30+ seconds.

[Horus 83]

@pettka @dwarden You need to add on BE whitelist procdump.exe and procdump64.exe.

Quote

 

D:\Drugi_F\Tools\Sysinternal\Procdump(1)>procdump -e 1 -f "" arma3.exe

ProcDump v8.2 - Sysinternals process dump utility
Copyright (C) 2009-2016 Mark Russinovich and Andrew Richards
Sysinternals - www.sysinternals.com

Error debugging process:
Access is denied. (0x00000005, 5)

 

 

[Dwarden 1125]

48 minutes ago, alexbu said:

 

Hey @dwarden (and all) some players and I already talked of this bug HERE

And we found out that use "-maxmem=2047" completely solved the problem. No crash anymore in most of the case

 

in such case it would indicate problems with the memory available (both ram/swap) or too bad fragmentation etc.

[real meatshield 10]

This has been going on since the release of apex, and you guys act like it's news? 

 

But hey, we got new footstep sounds in the jungle, so that's nice. 

[mistermonr0e 0]

Ever since I've switched over to the profiling branch I've ceased to have any problems with the FPS bug and a slight increase in performance (MBPr 15in using Bootcamp)

[Dwarden 1125]

1 minute ago, real meatshield said:

This has been going on since the release of apex, and you guys act like it's news? 

 

But hey, we got new footstep sounds in the jungle, so that's nice. 

 

those memory leak bugs are random and there were many, some people keep reporting similar issue since 1.5x some since post 1.64 some just 1.66 ...

 

trying pin it as single issue is probably going to be just another disappointment (as we recently fixed several leaks which were problem but not this problem)

 

 

[mrrbatty 1]

What I always find is that as soon as the client reaches the max memory allowed to be allocated by A3, it crashes. The memory just slowly creeps up until it hits that mark.

[JakobHT 1]

We run Hostile Takeover and would happily get a crew on a test server if needed. Gimme a couple days notice and I will get 50+ people on it no problem. It happens on KOTH frequently, I know you guys setup a test server for the zoom glitch if there is anything like that we can do to help I am there. Feel free to hit me up on discord I will get it fast. @dwarden  @pettka

[dnk 13]

I've noticed I get this A LOT due to vehicles getting destroyed. I was in a town with several vehicles burning, getting the customary 5FPS or so, then they all disappeared suddenly and 40FPS+.

 

Other times, a sudden crash/wreck will kick off the bug.

 

And then there's times it just happens because I've been on too long.

[Phactor 0]

I have experienced this problem before.  It seems to happen the most when I play on servers that are running the Invade and Annex COOP mode.  I usually play on these servers to practice with helicopters, so most of the time it happens I am flying around.  It tends to happen after an hour or so of playing.  I also play in a weekly private milsim PvP event that hosts up to 120 players for about 3-4hrs at a time and I have only seen the 3fps bug once in that setting.  We never play with AI and we run a very strict and limited set of mods.  I can't say whether or not I have played an equal amount of PvP to COOP, but I can say that I have experienced the bug many more times when playing with the AI.    This is all anecdotal but I hope it is helpful. 

 

EDIT: Ok after some quick math it would appear that I have played a roughly equal amount of COOP to PvP.

Edited February 7, 2017 by Phactor

[kuplion 18]

7 hours ago, dwarden said:

 

since 1.66 it's not recommended to use -maxmem= nor -maxVRAM= at all (the engine auto-detect and tries use maximum available)

it's now only fall-back for 'troubleshooting` or non-standard problematic hardware situations ...

Dwarden, out of interest, where was this mentioned prior to now (the updated wiki entry doesn't explicitly state it should no longer be used as of 1.66) as I can't find it mentioned in any of the 1.66 devhub posts? I feel changes like this should really be a little more publicised..

[Dwarden 1125]

why people keep asking about documentation when it's already there for quite some time ...

https://community.bistudio.com/wiki/Arma_3_Startup_Parameters#Performance

[kuplion 18]

28 minutes ago, dwarden said:

why people keep asking about documentation when it's already there for quite some time ...

https://community.bistudio.com/wiki/Arma_3_Startup_Parameters#Performance

 

You'll notice I clearly mentioned the WIKI lacking the information you've shared and suggested that maybe changes like this should be made a little more public as not everyone will be trawling through the WIKI after each update looking for changes.

-maxMem=<number>

Overrides memory allocation limit to a certain amount (in megabytes). 1024 MiB is a hard-coded minimum (anything lower falls back to 1024). The maximum is influenced by your operating system (any value over the maximum will be reverted to this value): 32-bit Windows + 32-bit game: 2047 64-bit Windows + 32-bit game: 3071 64-bit Windows + 64-bit game: (physical memory*4)/5 Without the -maxMem parameter the engine attempts to set this parameter internaly to a reasonable value often defaulting to max values as described above.  The file cache is always excluded from the virtual address limit, see our developers blog: https://www.bistudio.com/blog/breaking-the-32-bit-barrier. Note that setting maxMem to 2000 does not mean that the game will never allocate more then 2000 MiB. It says that the game will do everything in its power to not cross this limit.  In general, it makes sense not using this parameter at all and only resort to it in case you experience issues with memory.

-maxVRAM=<number>

Defines Video Memory allocation limit to number (in megabytes). Use to resolve e.g. Windows problem: http://support.microsoft.com/kb/2026022/en-us?p=1. Minimum value is 128 MiB (anything lower falls back to 128). The value is ignored (under DX11) if engine properly detected VRAM size, minus 20% reserve with ceiling limit 300MB max..

 

Nowhere here does it mention these parameters being depreciated in favour of auto-detection.

I only raise this as a concern as the 3fps seems to relate to a memory leak. In my experience at least using Performance build (and the v07 allocator) along with -HugePages and allocating a larger pool of memory via -maxMem seems to prevent the bug from appearing so frequently. I get it maybe once a week now, instead of once a play session.

 

[Greenfist 1863]

Should we be using the PERF builds here to avoid reporting any memory issues that are already fixed in it?

[WARHAWK_HT 0]

3 FPS glitch happens to my game only on multi-player whether it is nodded or unmodded. Pressing escape and waiting in the menu for a minute will sometimes temporarily fix it, but not usually. A full game restart is often required.

[Dwarden 1125]

@kuplion last line " In general, it makes sense not using this parameter at all and only resort to it in case you experience issues with memory. " is clearly self-explanatory ...

 

and -hugePages is completely unrelated parameter, which in fact with highly fragmented memory scenario can produce worse results ...  

while in ok memory state system it has positive effect due to saving CPU cache from too large allocation table ...

so best to not intermix stuff en random

 

you can't allocate 'higher pool' via maxmem as engine by default tries to use the maximum ...

[kuplion 18]

Just now, dwarden said:

@kuplion last line " In general, it makes sense not using this parameter at all and only resort to it in case you experience issues with memory. " is clearly self-explanatory ...

 

I'm sorry but in no way does that specify the 1.66 update. It's a casual recommendation at best.

 

Anyway, I was making a suggestion because communication is something that seems to be a bit hit and miss with BI. If you recommend a setting for a particular version, state it clearly and maybe people will have less issues.

[Dwarden 1125]

1 minute ago, kuplion said:

 

I'm sorry but in no way does that specify the 1.66 update. It's a casual recommendation at best.

 

Anyway, I was making a suggestion because communication is something that seems to be a bit hit and miss with BI. If you recommend a setting for a particular version, state it clearly and maybe people will have less issues.

it was added in 1.66 (easy to check BIKI history) and endlessly commented in profiling branch threads,1.66 hotfix and 64-bit related threads, Discord, Reddit w/e ... 

[kuplion 18]

Just now, dwarden said:

it was added in 1.66 (easy to check history) and endlessly commented in profiling threads and 1.66 hotfix related threads ... 

 

Do you not think that the average end user might not be trawling through all of these threads about profiling builds and hotfixes? Surely it takes two seconds to add it to a change log instead of expecting users to sift through dozens and dozens of pages of information just to find a mention of a parameter that's been in use for years now.

 

Seeing as this relates to memory and the 3fps bug, I was trying to be helpful in my suggestion that this kind of information may be more beneficial if made a little more public; I just won't bother in future.

[Dwarden 1125]

that was also mentioned in (at ending) https://dev.arma3.com/post/oprep-64-bit-executables and in the changelogs too ... 

but i do agree @kuplion we shall 'repeat' more 'loudly' more 'often' that certain command-line parameters aren't needed 

yet be aware that it happens quite often that some obsolete information stays around as urban myth no matter how hard we try to slay it :)

[kuplion 18]

Just now, dwarden said:

that was also mentioned in (at ending) https://dev.arma3.com/post/oprep-64-bit-executables and in the changelogs too ... 

but i do agree we can 'repeat' that more 'loudly' more 'often' that certain command-line parameters aren't needed 

yet be aware that it happens quite often that some obsolete information stays around as urban myth no matter how hard we try to slay it :)

 

Thank you @dwarden.

 

I do appreciate that settings become urban myths, which is why it's so important we all use the correct ones, IMO. I still remember discovering -High did nothing after using it for years because every guide said to use it. :D

[Guest]

3 hours ago, kuplion said:

 

Thank you @dwarden.

 

I do appreciate that settings become urban myths, which is why it's so important we all use the correct ones, IMO. I still remember discovering -High did nothing after using it for years because every guide said to use it. :D

 

Most of the guides are pure bullshit anyway.

[kuplion 18]

2 minutes ago, harmdhast said:

 

Most of the guides are pure bullshit anyway.

 

Amen to that. lol