fred41

@Kremator, i had a short look at the latest (PERF5) yesterday. The new range for maxmem (..3072) is a nice advantage. It increases the size of the large section object, from ~1,6GB to ~2,8GB. That should result in better streaming performance, especially on altis map. The only thing, that you as admin should keep in mind: it can only accelerate, if you really have the physical RAM, so that this section object is not paged to disk. So, if you use, for example, a large RAMdisc for your addon folder, it perhaps would make sense to free this allocated RAM and make it available for your OS memory manager. @JoneKone, indeed 4GB is not enough to have the advantage of large pages available. I wrote you an PM. @Viba, thanks :)

... nice ... UPDATE: v1.32 available via github (full update required) - fix: bug related to enableAPImonitoring, caused double slot usage with HC (thanks tankbuster, for report) - color difference between FPS&CPS increased a very little bit

@Tankbuster, i found a little bug (related to enableAPImonitoring=0). There is a fix in a smal update available (v1.32) on GitHub. Please try it out (complete update required) and let me know if it helps. Thanks and Greets, Fred41

... i meant color depth (24bit), because ASM uses very subtil color differences ...

@Tankbuster, ok thanks, i will look into it. @Numrollen, there are many possible reasons, that can cause problems, like low client FPS. The periodical CPS decreases, shown in your screenshot, are most likely caused by mission (scheduled scripts load), but that should not impact clients FPS directly. (could you please post screenshots with the full color resolution, that would make it easier to read all details) Greets, Fred41

@Tankbuster, thanks for your report. I had to add a 'alive' check in this latest version, because crashed arma server instances can left behind orphaned slots. It is possible that the used mechanism fails in some specific situations. I have the following questions: 1. is this problem always or just some times? 2. are all other values switching between this two instances too, or only AIR/AIL? Greets, Fred41

@ikomiko, that looks like a video card driver problem. An update could help, probably. @Lordprimate, this rc is a test binary only (see post #335 for details).

Is there a more detailed description for the HC kick reason? I will upload a new version of ASMdll.dll for testing. With this version you can disable the new API monitoring feature, by inserting/changing the following entry in asm.ini: enableAPImonitoring=0 Just in case BattleEye has a problem with API monitoring, this could/should help. Please let me know how it works.

Is the problem solved with dwardens solution?

Ok, i think i understand your problem now. Your both applications arent working if arma is started as administrator, right? So the only way to make large pages available for arma, is that you make a new, normal user account (without admin rights) and log in this account for running arma. Don't forget to set the 'lock pages in memory' privilege for this new acccount and to restart once. That should work, because you now can start arma normally (as non admin user). Hope it helps, Fred41

... hmmm, i am trying to understand your problem, but i am a bit unsure ... How are your applications working, when you use arma without 'malloc=tbbmalloc' and as administrator? Why do you start arma as administrator?

... i am really impressed, Th4d ... :rolleyes:

@Th4d, amazing? I wish it would be a bit more amazing :) All numbers on arma client are measured, with Helos A3 benchmark (in a scientifically correct way) and in relation to BI's default allocator. However, the thread related to the LP allocator is here: http://forums.bistudio.com/showthread.php?163640-Arma3-and-the-LARGEADDRESSAWARE-flag-%28memory-allocation-gt-2GB%29 Greets, Fred41

25% more memory access speed can have very different effects to armas overall performance. A arma client, for example, will have (dependend of used settings) probably other bottlenecks in the foreground, so that you just see maybe 6% more FPS. With other settings (better adapted to your hardware) you can see 9% more FPS. On arma server, the usage of large pages means most likely more increase, but it is very difficult to express the difference in numbers. I think this is not negligible, considering it is free (not counting the hours i spend on it :) ) The reason, why i replied to your post in this thread, is that i basically hold dear the technically correctness of your posts, and i got the impression, that the post i replied to, was an exception in respect thereof ;) Greets, Fred41

Yes, todays cpu cycles are already in the pico second ranges and the common ddr3 RAM is already a heavy bottleneck. The cache locality (first and second level cpu cache) of a framework like arma, is very poor (bare in mind the large ammount of data in the GB range processed continously). So every little more memory bandwith counts. This is the reason, why faster clocked RAM has that great effect for arma. The use of large pages, provides a ~25% acceleration of all main memory accesses (read and write) and this for free. So, why not using such advantage for arma? And yes, i prefer 64 bit applications too, and i really wish we will see this soon for arma. Not because i expect a big performance increase (maybe 10%), but because it makes things easier for programmers, if an (practical) unlimited virtual address space is available. Greets, Fred41

... i am looking for testers (server admins), to test the long time stability of a new 'tbbmalloc for arma' build ... Requirements: - root server (full restart once, is required) - 64bit OS, 8GB+ RAM - admin should be familiar with 'tbbmalloc for arma' and able to setup it correctly (lock pages in memory privilege) - server instance should run stable and proved mission(s) and be mostly well populated - instance should run at least 2 days without restart Motivation: Normally the amount of memory allocated by arma server increases over time and a instance restart is required at least each few days. The goal of this test is, to find out if the memory consumption of this new allocator is significantly lower for a long running instance, compared with other allocators (old and new default BIS allocators, current stable tbbmalloc). Please PM me, if you are interested and able to help here, Fred41

... maybe this link is a good start for your research: http://msdn.microsoft.com/en-us/library/windows/desktop/aa366720%28v=vs.85%29.aspx Greets, Fred41

... just a short feedback from a players point of view ... One hour on CZ04 (samatra wasteland v11, altis), 60-70 players and framerates between 50-60 FPS. Later very smooth experience with (vsync on 50Hz). Absolutly playable, Fred41

@SpanishSurfer, while i am not dwarden, i think i can answer your question. With todays stable branch update, a new allocator, based on intels latest build (4.2 update 3) is available for everybody. This allocator has some improvements, compared with the old default allocator, and i hope that BI's developers continue, to optimize this important part of the arma distribution. Generally i would say: If you have a 64bit OS and 8GB+ RAM and you are able to set the required privileg (lock pages in memory) and manage a clear system, then you should still use 'tbbmalloc for arma'. It's just still a bit faster, especially because of LP usage. (See initial post, for an updated list of advantages). If you don't have a modern system or you just prefer the easy way, you have a good allocator with the unmodified latest stock allocator from intel (BI's default allocator) too. If you are still in doubt, just compare it in real life :) Greets, Fred41

... very good idea, this survey ... The only infos i miss are OS details like: 32/64 bit and 7/8 or 8.1 version. (i personally run my monitor at 50Hz, but had to select 60Hz in survey, because 50 is not available) Thanks for your effort making this survey available, Fred41

minor fix: AIR showed sometimes strange values like '65535'. Reworked units calculations (fn_ASM.fsm) should fix this behavoir. Only ASM.pbo have to be replaced this time.

... just now updated to 0..5000 kByte/s for NTI/NTO/DIR ... Additional, this values are now sampled each second (4 seconds before). ---------- Post added at 18:48 ---------- Previous post was at 18:29 ---------- ... indeed it is possible, but it shouldn't happen ... Do you get any error message or does ASM just not displaying the expected data?

UPDATE: - added new API values NTI & NTO (Network Traffic In/Outcoming) in kByte/s - added new API value DIR (DIsc Read) in kByte/s - MEM value is now available in history graph too - some little fixes/rearangements The 3 new API values have to be scaled for optimal displaying in the history graph. As initial scale, i selected a range of [0 .. 2500] kByte/s, lets see how it works on full servers. Just let me know your suggestions if the scale doesn't fit for you. Greets, Fred41

... thanks for your logs too ... The only suggestion i have for you: Upgrade to 8GB or more RAM, if possible, to get the best memory performance. Greets, Fred41

... really good news, thanks ...