TheFlyingCorpse

Featurerequest for a new version: For performance: - cpuCores - maxMem - exThreads For lazyness: - Steamcmd compatability so it can also update the server For stability: - Auto restart of game on crash + on a schedule, example every sunday. Should be combined with check if patch for game + server is available to do it "the coming morning" or right away.

Am I correct in my assumption that what the serverside does is just give out the 400 bytes of information stored in ram? The data looks exactly the same. Are these assumptions correct? - DWORD = 4 bytes - CHAR = 32 bytes total (for profile / mission). How hard would it be for it to "just" be handing this out via XML-RPC or a similar interface? Its really hard to query this via TCP being a custom socket. The same being accessing the parts via ram. This way you may modify it in the future, change and the calcs etc, without having to worry about breaking anything reliant on the hardcoded structure it is today. The amount of data in this regard, having a custom socket doesn't really speed it "down" if it can handle XML-RPC or a more standardized interface than the custom it is today. A few peers I asked to assist on fetching data via the TCP socket said they'd at least expect a \r\n at the end to signify its now recieved. I've made a C# app that uses the shared memory mapped file, its "close" but no cigar, I dont know how you calculate the FPS or if its expected to always be X digits, place the "dot" here. The memory is ok, easy enough to guess. Also in ASM, the process id is in HEX, not in Decimals ;-)

Can't say I measured it. I used Server 2012. What kind of CPU? I'm considering to get a i7-4930k for a new dedicated and clock it to 4.5GHz, based on the assumption that ArmA server will use two cores, ArmA client will use two cores, then two cores for OS + network.

ramius86, I think you got some very good numbers there. local client or on dedicated hardware? CPU(s)? I ran mine on an i7-4770k.

I went ahead, pulled together the different sources on DAC from this board (no credit to me on that end) and made a simple ArmA 3 Headless Client test. The HC feature is parameterized, enable this before loading the map as admin to notice a great difference in performance. Note you will lag in the end, this mission runs up to 1000+ AI when both sides are spawned. Step close to the boat to get the baddies to spawn. Demo map: http://www.mediafire.com/download/mhjsycsg21yr9fj/a3_hc_test.Stratis.pbo 1st half is without HC on the graph below. The 2nd half is with HC. Its 500 AI the max+ (the graph caps out around 450 AI spawned)

Might there be an option where you can dump the data recieved into a folder specified by argument, example: - Dump the data obtained every 10s (just that sample from that 10th second) (argument for how often) to a flat file with a name like profile.<epoch> or similar, inside it you dump each type on a new line, eg: FPS=VALUE This way, the process to fetch and process the data is no longer on the gaming server if the parser is connecting remotely. This way, you can also change it as you please in the future, adding and removing the data types without worrying of screwing up the interface for the parser. Then its quite simple for anyone to take use of the data as well, being it RRD (for those of us who prefer that) or something else. The issue I see is that its not that easy to find a unique key to identify the instances, other than profile name, here being "default" in most instances. With several servers running on the same monitor, this might be an issue if they all run with "their" default. I have no way of separating them then to separate stores, unless the ASM stores each instance in its own folder with some internal logic to identify each. Thoughts?

The "web interface" will probably be very simple, written in either perl or python as I want to stay platform independent hoping ArmA III server in the future supports Linux ;) What I'd probably be able to write is a simple tool that can open a connection, query and take the recieved data and store it to an RRD file. it can then also generate a graph based on this every X seconds (custom location) so it can be put on a webpage. Should not be too hard, albeit I'm stuck with the UDP connection/socket handling so far. Edit: NVM on the UDP, ASM doesn't listen on UDP.

Thanks for this great tool Tophe, really appreciate it!

Thanks for hosting the files on github, however the source is not there =( I see great potential in this tool and a good foundation has been made, however I wish it could output it some way so I can store it in an RRD or similar for generating graphs to put on a webpage. For debugging purposes of missions the existing implementation is complete, I want a bit more though (-: Thoughts? I only need to know how I can get the data, tried a wireshark trace, didn't get quite much from that in regards to the packet/data structure (I'm a noob, I know). The documentation is a bit unclear if you still need to edit maps for this to work, from what I've tested with, you don't as long as the mod is loaded on the server, is this correct?

New to bug reporting to ArmA 2, but after playing with the clan earlier tonight, we' decided to hit the issue head on. I've washed the data some, but not all of it, to make it easier to sort on duration. The findings detail that normal for my computer is duration between 0,03 to 0,05, I have some below and some above. The real eye opener that didnt fit the pattern was durations of 0.5, spot on, several times. Please look here for further details on the findings, I believe the lag experienced is caused from a loop or script that suddently for some cause takes too long and times out during execution. https://docs.google.com/spreadsheet/ccc?key=0AspafWueokkydGI2RUdVN2JQSUpROXFWd2JKREhDYmc (the logs are synced with SSG's)