fred41

@ramius, reaching the 2GB border with altis map should really not be a problem. Empty mission starts with 1.1GB (client), small missions starts with ~1.3GB, and dependend of the mission and player number it normally slowly grows to above 2GB (max. seen by me 2.4GB). I use processexplorer from sysinternals for measuring. @Windies, lets hope for real 64bit arma in the near future ... @Dwarden, yes, thats exactly what i have to assume now. I tested yesterday with both tbb 4.0 and tbb 4.2, more than 1 hour each (maxmem not used/set). Both runs with perfect FPS normally between 40 and 50 (vsync on). Max. memory ~2.2 for each of both tests (BECTI 0.9 on altis). Also, there is no important difference between 4.0 and 4.2, maybe 4.2 is a tick better (just a feeling). The difference i observed in the last days (problems disappear), seems to be only caused by improvements/changes in the engine (DEV branch). PRELIMINARY CONCLUSIONS: tbb4malloc_bi.dll works well enough, currently dont use maxmem without a need (64bit OS, enough physical RAM) Greets and a HAPPY RELEASE :) Fred41

Hi dazhbog, i use windows7/64bit. I changed from maxmem=2048 to 3072, just to make sure this is not limiting and i did it already before i tried the newer tbbmalloc.dll, based on intels current source code version 4.2. (there was at least a chance, that maxmem range is already extended, because we are in the DEV branch ...) If i understand this: http://forums.bistudio.com/showthrea...=1#post2481817 correctly, the recommendation for a modern system with 64bit OS and 8+GB RAM is: "dont use maxmem and let arma 3 change internal limits automatically" ??? If so, i will try to reproduce the problems, without maxmem set, and compare the performance with both, the 4.0 and 4.2 malloc .dll's. Greets, Fred41

Hi Das, thanks for testing. The difference should be observable, at the point where armas memory allocation is near 2GB. On altis map, this point can be reached very quickly (1/2 - 2 hours, depends of your mission). With the original tbb4malloc_bi.dll, trouble starts for me at 1.8-1.9GB memory on client (pure fps, <10 instead of 40-50 before). I set maxmem=3072, used the new tbbmalloc.dll and have no problems now, at around 2.2 GB (didnt tested longer). Fred41

Hi Bakerman, thanks for your offer to help here. tbbmalloc.dll is already linked with the /LARGEADDRESSAWARE flag set, so there is no need to change the binary later. Please try the new custom malloc (on server or client) and let me know your results, Fred41

Hi Das, some basics about the BIS custom memory allocator are explained here: http://community.bistudio.com/wiki/ArmA_2:_Custom_Memory_Allocator In short, the memory allocator is the interface library for allocating/freeing pieces of memory indirectly from/to available system memory. Especially the intel tbb_malloc is a well known, fast and solid allocator, used by BIS in version 4.0. Meanwhile there are some bugs fixed and some features added by intel, so the current version 4.2 is a bit more improved. The LARGEADDRESSAWARE flag, on the other hand, is a flag which is introduced by microsoft, to allow 32 bit applications to indicate, that they are able to use memory addresses above 2GB in a correct way. So i offer here a newer memory allocator library for testing. Maybe we can help BIS this way, to circle the current memory issues. Greets, Fred41

@Terox, just a "signing newbe" question: What advantage has serverside (only) signing? I mean, i dont really understand, why should one sign addons, which are never running on other clients? Thanks, Fred41

HC's automatic slot occupation is currently not working as expected. A possible workaround will you find a few posts earlier (inch). If you add this: init="this allowDamage false;if (profileName==""HCXX"") then {selectPlayer this;};"; // replace HCXX with the -name param from HC client start line to your HC vehicle initline, at least your HC should start correctly, (just in a wrong slot) and should work. Maybe you also have to replace: BTC_HC_name = name player; with: BTC_HC_name = profileName; Hope it helps, Fred41

... yes, spawn the AI where you want it to be simulated (.fsm processing), normally on HC, if available. Later changing the locality (setOwner) is possible, but means more effort (e.g. waypoints are lost) ...

Hi Byrgesen, NeoArmageddon said it, the AIR value shows you how many remote AI is alive. But AI local on other clients is included here too, so it could make sense to monitor the HC additional. If your HC is heavy loaded (COOP mission, 300+), some other values could be interesting too. So, if you need more detailed data from your HC instance, you could sign @ASM by yourself. That should have no disadvantages, because the @ASM mini-addon is not shared with your clients (except the HC) and is just meaned as simple way to start the fn_ASM.fsm. Greets, Fred41

Hi Inch, your init line locks not that good. Just use a text editor and insert the original line from my earlier post in your mission.sqm file (dont forget to adapt the HC name in that line). Currently BIS requests a extra license for the use of HC (you need a full additional license). That maybe change in future (and i really hope so), but your steam kick could be related to this license restriction. Also, if you use the loopback=true command in your server.cfg (for testing, developing), you schould know it doesn't work currently. (I tinkered for hours with loopback=true a few weeks ago and got just steam kicks). So currently, the only way to make a HC running, is to buy a additional license for HC. Greets, Fred41

@Inch, the battleyeLicense=1; line have to be in your HCXX.Arma3Profile file, where HCXX is the -name=HCXX you assigned in the HC start command line. Example HC start command line: "c:\Steam\steamapps\common\Arma 3\arma3.exe" -client -localhost=127.0.0.1 -connect=localhost -noPause -nosound -world=empty -profiles=d:\A3\headlessclient -name=HCXX You should find the profile here (you have to start the HC once): d:\A3\headlessclient\Users\HCXX\HCXX.Arma3Profile. This could solve your BE problem. The automatic slot-occupation/mission-start for your HC vehicle, currently doesn't work correctly (at least at my last try in DEV branch). Mostly your "rabbit" jumps in a regular west/east player slot, even if it was configured as civilian. To force a mission start of your HC, before a player connects, you could add the following in the init line of your HC vehicle (mission.sqm): init="this allowDamage false;if (profileName==""HCXX"") then {selectPlayer this;};"; Hope it will help you, Fred41

... i wouldn't call it injection, there is just a autostart function define in CfgFunctions, used to launch fn_ASM.fsm at mission start. This FSM reads/measures periodical some performance values from inside the DS and WRITES the data in a shared memory area (in swap file). This way different processes (DS -> ASM) can exchange data very fast, currently in one direction. I think, using this monitor tool to control your server (and maybe connected clients), would exceed the primary meaning of a monitor tool a bit, even if technical possible. But the idea is very interesting, maybe i rethink my current attitude later :) Thanks for your feedback and recommendation, Fred41

You are right, the highest IO load, will be always observed at mission start. If you check the real IO behavoir of Arma3Server.exe while running a mission, then you will notice, that a lot of data are still readed frequently (noncached) from the Addons folder. To verify this, you can use the following tool: http://live.sysinternals.com/Procmon.exe By filtering for Arma3Server.exe and only file access, you get a clear notion of DS file-access pattern. Conclusion for me is, it can make a big difference, not only on mission start, where your data are physically located . Especially the FPS drops caused by IO peaks, can be significantly reduced, by moving the Addons folder to a physical ultra high speed drive (RAM-disk). All you need is RAM :) Greets, Fred41

UPDATE: userinterface improvements, thanks zach72 for very good ideas history graph on/off switch (popup menu) number of displayed instances, selectable range 1..4, (popup menu) stay on top on/off switch, (popup menu) For this update, you only have to update the ArmaServerMonitor.exe binary from my github repository. ENJOY :)

... your params looks correct. Try the following: Start the first ASM instance without params (defaults to: -server -n1 -h127.0.0.1 -p24000) local on server device. Start the second ASM instance local on your server device too, with: -client -h127.0.0.1 -p24000. If this connection works (Request/Update in title line of ASM), then you know the problem is still in your firewall(s) configuration. Let me know, Fred41

... ASM-server is listen on one local port for TCP connection attempts (default port: 24000). Assuming you use the correct set of ASM command line params (for server and client), all you need is to open your firewall for this ONE selected port for INBOUND connections. This normally means, you have to create only ONE new INBOUND rule, in your advanced firewall settings, like this: profile: public action: allow protocol : TCP LocalPort: 24000 (or what port you prefer) (all other is ANY or default) Hope i could help you. If not, post your commandlines, both server and client side. Fred41

... unexceptional signed and always looking forward, Fred41

... yes, your setup seems to be a good solution. I think, the IO peaks related to log-file writing are mainly a problem, if you have the log files on the same drive as your frequently readed "Addons" folder. In this case, you have massive reads and writes concurrently!!! But, if you have your whole "Addons" folder in a RAM disk (ultra fast, separate drive), then you could keep your log files and maybe your iniDB on persistent HDD. This way you have both, insane performance and highest data security. Greets, Fred41

... really glad to hear it :) Thanks for your suggestions, this are a lot good ideas. Related to password protection, i think you can protect your (not really sensible) server performance data good enough, by changing the default port to something else. In combination with restricting the number of clients, this should provide a appropriate security. The current user interface, you are absolute right here, is a bit rudimentary, but at least it works :) There are plans for a web browser interface in the future, which could make ASM a more nice looking toy. But i will think, how to implement some of your ideas in the current (Delphi 2006) ASM as soon as possible. I think for this kind of usage, ASM will really help you. A next step could be, optimizing your favorite missions and verify your progress with the help of ASM. Greets, Fred41

... this ASM-client command line looks perfect. I tried to connect your ASM-server from my local ASM-client, got error 10060 (timeout). Wireshark record show me, that there was NO answer packets received from your side. Either your ASM-server was not running OR/AND your firewall is still blocking the port 24000. Did you tried ASM-server and ASM-client, both together, local on your server machine? Never give up :) Fred41

Yes, first: - ASMdll.dll and asm.ini have to be in your ARMA2 root folder (where the armaXserver.exe is) - fn_ASM.fsm have to be in your MISSION root folder (where init.sqf is too) second (i am assuming, your ARMA2 server doesnt run on the same system as your ARMA 3 server): - it seems the "Microsoft Visual C++ 2010 Redistributable Package" is not installed on your OS where ARMA2 is running! (Re)install this: http://www.microsoft.com/en-us/download/details.aspx?id=5555 Good luck, Fred41

... maybe this step is essential part of the described methode? I do it per default (CTRL+ALT+DELETE and than switching back to arma) at beginning of each arma client session. This results in an FPS increase from 25.0 to 50.0 (vsync on). Maybe it helps you too guys, Fred41

... a lot of RAM can really speedup your Arma 3 server if you use it in an optimal way. If you have enough RAM to hold a copy of your whole addon folder in a RAM disk (current DEV branch ~ 9.5GB ), there is no need for a SSD or a fast RAID anymore. As example: Rename your "Addons" folder to "Addons_hdd", copy the content to a folder in your RAM Disk (z:\Addons) and make a link in Arma root folder, pointing to the data in RAM disk (mklink /D Addons z:\Addons). You just have to ensure the whole folder is copied to RAM disk at system start (via scheduled batch/cmd file) and written back if a STEAM update was applied. Hatchet_Harry, there is no risk at all, the data in addon folder are only readed (not modified). Regards, Fred41

Hi zach72, your command lines are looking good (except the triple quotes in the client line). Did you open the port 24000 for TCP?. This is important and wont work otherwise. Arma 2 is not supported with the addon install method, because the preInit param, i used to start the fn_asm.fsm in cfgFunction, is not available for Arma 2. But, if you pack fn_ASM.fsm in all missions you wish to monitor, you could start it by insert a line like this: if (isServer) then {[] execFSM "fn_ASM.fsm";}; in your init.sqf. In this case there is no need for the addon, you only need the ASMdll.dll (and maybe asm.ini) in root folder. (There is an other way to start fn_ASM.fsm, using extendet eventhandlers from CBA mod, see an earlier post from terox in this thread.)

... wow... just discovered your tool and played around with it. That is, what i was searching for a long time. Really awesome work !!! Thanks for that, Fred41 BTW: Maybe the current workflow could be accelerated, by the additional ability, to append object data automatically to a specified file (using callextension). Just an idea :)