Polymath820

I can offer you some advice when it comes to college, you don't have to code for hours to come up with a brilliant solution. http://cs.stanford.edu/people/eroberts/cs201/projects/crunchmode/econ-hours-productivity.html The second a loop on the server you can use if (isDedicated) or (isServer) then { while {some condition of truth} do { }; }; if all you want it to do is run on the server then if (isDedicated) then { while {condition} do { }; }; Else if this is going to be executed multiple times pre-compile it.

Fixed. Lock / Delete.

I should have clarified what I said I wasn't idle I was idle in-game but the server wasn't idle. It was actually Bohemias Zeus server an US one and it was NATO Zeus Master Altis with 100% of the slots filled there was a lot of activity going on in-game. I'll try and get a 240 second recording. Now here is a bit of interesting information. Lets throw CPU graph Storage and memory activity into one Analysis page. Which will link the time differences together. http://i.imgur.com/pK3U9yn.png (214 kB) There is actually no relationship between the memory being mapped and the CPU. But I will do a more detailed recording see what I can get out of it. http://i.imgur.com/tz5CTvF.png (150 kB) Both traces seem to only find a relationship between CPU time, and thread use and thread-time-line and again a full Zeus server worker threads ARE doing... wait for it.... nothing...That being said the thread operation time seems to be taken up by Readying Threads and Context Switching them? So events seem to be the primary thing taken up time on the CPU by their raw-count? The events graph is the closest match to the Thread-utilisation graph. So if this is so why is arma 3 doing a lot of thread readying and context switching? Page faults appear to have no relationship. Nor do read-write operations. http://imgur.com/2Qb2vv4,YP3bVMc I think this is more than conclusive to say arma 3's multi-threading is inefficient. It's quite fascinating to note Battle-Eye has a very linear relationship when it comes to commiting memory. Very linear.

Want to know intricate details of what ArmA 3 is doing? http://www.microsoft.com/en-US/download/details.aspx?id=39982 Download it and only install the performance and evaluation kit. Start ArmA 3 join a server Run Windows Performance Recorder,run it as admin and compatibility windows 8 set it to "Memory" and Verbose. Select GPU and CPU trace Record 160seconds or more if you like Run GPU-View as Adminstrator and In compatibility mode windows 8 or which OS Run Windows Performance Analyser Find where you saved the data-recording Open The recording saved in GPU-view and Open it in Windows Performance Analyser. That will give you enoromous amounts of information about how arma 3 works. It seems to me arma 3 maps too many memory mappings. No joke... and 10 threads are opened over a 160 second GPU trace used < 1% of the time. My question is due to ArmA 3 mapping enormous amounts of unnecessary memory could be reduced? P.S if you want to know what a server is doing you can remotely run this program as well. In the event you want to analyse what ArmA 3 is doing server-side and where performance bottlenecks exist. The amount of data you get is not limited how often a thread is put in a wait state, how long a GPU execution takes CPU, and HW-queuing. and as far as I know you can listen in frame-draw-calls and how long they take to execute. Direct3D 11 texture mapping SO MUCH DATA> Heres an idea of the type of things going on with arma 3 Standard queue packet Submission Sequence: 66618 SubmissionTime: 557203572 (55,720.3572ms) CompletionTime: 557724652 (55,772.4652ms) Time in SW queue: 52 milliseconds Dma size (bytes): 76 Number of allocations referenced: 91 Number of patch locations: 91 ---------- Associated Dma Packet(s) follows ----------- DmaPacketList size=1 Creation Time: 557662569 (55,766.2569ms) Process (5532) arma3.exe Context: 0xFFFFC00104EA5210 Standard Dma Packet Submission fence: 5927772 SubmittedToHardwareQueueTime: 557662960 (55,766.2960ms) GpuStartProcessingTime: 557701996 (55,770.1996ms) CompletedByISRTime: 557724390 (55,772.4390ms) CompletedByDPCTime: 557724622 (55,772.4622ms) Time in HW queue: 61430 (6.1430ms) Execution time: 22394 (2.2394ms) Packet Status: Completed Queue Packet: Dma Size (bytes): 76 Queue Packet: Number of allocations referenced: 91 Queue Packet: Number of patch locations: 91 Allocation References: 0x0000000000000000 0xFFFFE0004C3B1C20 0xFFFFC000FDFFFBF0 P0 App 0x0000000000004000 (16KB) 0xFFFFE0004BEFDD70 0xFFFFC001051FCAD0 P0 App 0x0000000000010000 (64KB) 0xFFFFE0004F4B2010 0xFFFFC0010D026630 P0 App 0x0000000000001000 (4KB) 0xFFFFE000504C3010 0xFFFFC001095B68E0 (w) P0 Mem 0x0000000000023000 (140KB) 0xFFFFE0004FA6CA20 0xFFFFC000FE666840 (w) P0 Mem 0x000000000000A000 (40KB) 0xFFFFE0005048E7B0 0xFFFFC001049F0E00 P0 Mem 0x0000000000002000 (8KB) 0xFFFFE0004C45A2F0 0xFFFFC00104539D80 P0 Mem 0x00000000000C0000 (768KB) 0xFFFFE0004ED25930 0xFFFFC000FB7FA6F0 P0 Mem 0x0000000000290000 (2MB) 0xFFFFE0005096CA50 0xFFFFC00105188010 (w) P0 Mem 0x0000000000010000 (64KB) 0xFFFFE000521D87D0 0xFFFFC0010444AC20 (w) P0 App 0x0000000000001000 (4KB) 0xFFFFE0004D4174B0 0xFFFFC00104ABA280 (w) P0 App 0x0000000000001000 (4KB) 0xFFFFE000514C7290 0xFFFFC0010D1C0080 (w) P0 App 0x0000000000002000 (8KB) 0xFFFFE000514D1DA0 0xFFFFC0010CB88E00 P0 App 0x0000000000100000 (1MB) 0xFFFFE000521B7540 0xFFFFC000FB34C010 (w) P0 Mem 0x0000000000100000 (1MB) 0xFFFFE0004F2CE990 0xFFFFC0010805C4B0 (w) P0 Mem 0x0000000000880000 (8MB) 0xFFFFE0004F935F70 0xFFFFC00103490D90 (w) P0 Mem 0x0000000000800000 (8MB) 0xFFFFE00052B603D0 0xFFFFC0010D0BD6C0 P0 Mem 0x0000000000014000 (80KB) 0xFFFFE0004FFD1B20 0xFFFFC00103E22A20 P0 Mem 0x0000000000020000 (128KB) 0xFFFFE00051EDC550 0xFFFFC00107FA1010 P0 Mem 0x0000000000020000 (128KB) 0xFFFFE0004ED0E840 0xFFFFC00107DC36B0 P0 Mem 0x0000000000004000 (16KB) 0xFFFFE0004C828570 0xFFFFC00104EBF010 (w) P0 Mem 0x0000000000040000 (256KB) 0xFFFFE0004ED87D90 0xFFFFC001098DFA90 (w) P0 Mem 0x0000000000001000 (4KB) 0xFFFFE000513B3930 0xFFFFC0010CA19C80 P0 App 0x0000000000140000 (1MB) 0xFFFFE00050AA72E0 0xFFFFC000FBFDFE00 P0 App 0x0000000000020000 (128KB) 0xFFFFE0004FBBACD0 0xFFFFC000FF360010 P0 App 0x0000000000800000 (8MB) 0xFFFFE0004E452180 0xFFFFC0010D1B4270 P0 App 0x0000000000020000 (128KB) 0xFFFFE000504768D0 0xFFFFC00109358C00 P0 App 0x0000000000020000 (128KB) 0xFFFFE000501F9F70 0xFFFFC00104959010 P0 App 0x0000000000020000 (128KB) 0xFFFFE000501755B0 0xFFFFC000FF2A6410 P0 App 0x0000000000004000 (16KB) 0xFFFFE0004DF423A0 0xFFFFC00108E7FE00 P0 App 0x0000000000400000 (4MB) 0xFFFFE00050BD8600 0xFFFFC000FC40F010 P0 App 0x0000000000020000 (128KB) 0xFFFFE000518611B0 0xFFFFC00104B11900 P0 App 0x0000000000008000 (32KB) 0xFFFFE0004F4DEE50 0xFFFFC00109685800 P0 App 0x0000000000800000 (8MB) 0xFFFFE00051477010 0xFFFFC00103F15B60 P0 Mem 0x0000000000008000 (32KB) 0xFFFFE00050875290 0xFFFFC0010D35D750 P0 Mem 0x000000000002B000 (172KB) 0xFFFFE0004C8316C0 0xFFFFC000FCF22590 P0 Mem 0x0000000000060000 (384KB) 0xFFFFE00051EC6F70 0xFFFFC00103E1A470 P0 Mem 0x0000000000016000 (88KB) 0xFFFFE0004C6692C0 0xFFFFC00104207490 P0 Mem 0x0000000000016000 (88KB) 0xFFFFE0004F5B0180 0xFFFFC0010B7EA7A0 P0 Mem 0x0000000000060000 (384KB) 0xFFFFE00050219260 0xFFFFC0010515BE00 P0 Mem 0x0000000000016000 (88KB) 0xFFFFE000501AAB30 0xFFFFC000FC6C0010 P0 Mem 0x0000000000060000 (384KB) 0xFFFFE0004FFDB3B0 0xFFFFC0010D550660 P0 Mem 0x0000000000016000 (88KB) 0xFFFFE00050BE5C30 0xFFFFC0010C51E010 P0 Mem 0x0000000000016000 (88KB) 0xFFFFE0004F41E980 0xFFFFC000FC6C32F0 P0 Mem 0x0000000000016000 (88KB) 0xFFFFE0004ECDA4B0 0xFFFFC00108E58800 P0 Mem 0x0000000000060000 (384KB) 0xFFFFE0004C831620 0xFFFFC001041E9420 P0 Mem 0x000000000002B000 (172KB) 0xFFFFE0004DF42010 0xFFFFC0010C366270 (w) P0 Mem 0x0000000000220000 (2MB) 0xFFFFE0004F81C2C0 0xFFFFC000FDF094C0 P0 Mem 0x0000000000014000 (80KB) 0xFFFFE0004FBDC010 0xFFFFC0010404F010 P0 Mem 0x0000000000020000 (128KB) 0xFFFFE0004F75CAE0 0xFFFFC00103561420 P0 Mem 0x000000000002B000 (172KB) 0xFFFFE0004C37C3D0 0xFFFFC0010C8CD8A0 P0 Mem 0x000000000002B000 (172KB) 0xFFFFE0004F78A300 0xFFFFC001038CB190 P0 Mem 0x000000000002B000 (172KB) 0xFFFFE000504BB9F0 0xFFFFC0010C9ED4D0 P0 Mem 0x0000000000014000 (80KB) 0xFFFFE0004FFD0560 0xFFFFC00103804010 P0 Mem 0x000000000002B000 (172KB) 0xFFFFE0004F3F88D0 0xFFFFC0010BCB1320 P0 Mem 0x000000000002B000 (172KB) 0xFFFFE00050114C90 0xFFFFC000FEA86E00 P0 Mem 0x0000000000016000 (88KB) 0xFFFFE00052F06290 0xFFFFC0010C40E010 P0 Mem 0x0000000000060000 (384KB) 0xFFFFE0004D4445B0 0xFFFFC00103471920 P0 Mem 0x000000000002B000 (172KB) 0xFFFFE00050B64250 0xFFFFC00107CE7880 P0 Mem 0x0000000000014000 (80KB) 0xFFFFE0004FF88F70 0xFFFFC0010C51E310 P0 Mem 0x0000000000020000 (128KB) 0xFFFFE0005226E0C0 0xFFFFC00103CFC5B0 P0 Mem 0x000000000002B000 (172KB) 0xFFFFE0005085BA60 0xFFFFC00103461970 P0 Mem 0x0000000000060000 (384KB) 0xFFFFE000502EEB10 0xFFFFC0010BC827A0 P0 Mem 0x000000000002B000 (172KB) 0xFFFFE000509F2980 0xFFFFC00103C65010 P0 Mem 0x0000000000018000 (96KB) 0xFFFFE0004DF572C0 0xFFFFC0010956DE00 P0 Mem 0x0000000000020000 (128KB) 0xFFFFE00050A094C0 0xFFFFC001090B37B0 P0 Mem 0x0000000000008000 (32KB) 0xFFFFE00050BDDB90 0xFFFFC000FE1C7420 P0 Mem 0x0000000000001000 (4KB) 0xFFFFE00050476E00 0xFFFFC000FB864E00 P0 Mem 0x0000000000018000 (96KB) 0xFFFFE00051C7DD30 0xFFFFC000FDDFA810 P0 Mem 0x0000000000020000 (128KB) 0xFFFFE0004F69CA80 0xFFFFC0010C660010 (w) P0 Mem 0x0000000000011000 (68KB) 0xFFFFE0005093E990 0xFFFFC000FF3FD620 (w) P0 Mem 0x0000000003FC0000 (63MB) 0xFFFFE0004F45D110 0xFFFFC00108147720 (w) P0 Mem 0x0000000001FE0000 (31MB) 0xFFFFE00050905310 0xFFFFC0010D687010 (w) P0 Mem 0x0000000000400000 (4MB) 0xFFFFE0004C396890 0xFFFFC00108057280 P0 Mem 0x0000000000001000 (4KB) 0xFFFFE0005252F830 0xFFFFC0010A3C77B0 P0 Mem 0x0000000000014000 (80KB) 0xFFFFE0005267F4E0 0xFFFFC0010A4CE680 P0 Mem 0x0000000000020000 (128KB) 0xFFFFE000504FD9A0 0xFFFFC0010C8CDE00 P0 Mem 0x0000000000060000 (384KB) 0xFFFFE0004F3D0100 0xFFFFC0010D884E00 P0 Mem 0x0000000000016000 (88KB) 0xFFFFE0004CD81A80 0xFFFFC00107F3CA20 P0 Mem 0x0000000000016000 (88KB) 0xFFFFE00050326CA0 0xFFFFC00104940E00 P0 Mem 0x0000000000060000 (384KB) 0xFFFFE0005166DB20 0xFFFFC000FE1BB3E0 P0 Mem 0x0000000000014000 (80KB) 0xFFFFE00050502B80 0xFFFFC001038FF010 P0 Mem 0x0000000000020000 (128KB) 0xFFFFE0004CF64BE0 0xFFFFC000FCFF6780 P0 Mem 0x0000000000060000 (384KB) 0xFFFFE0004FFBA4C0 0xFFFFC000FEA4FE00 P0 Mem 0x0000000000060000 (384KB) 0xFFFFE0004ECA9AD0 0xFFFFC0010D022220 P0 Mem 0x0000000000014000 (80KB) 0xFFFFE0004F377160 0xFFFFC0010C88E5F0 P0 Mem 0x0000000000014000 (80KB) 0xFFFFE0004D4C9930 0xFFFFC0010DE55010 P0 Mem 0x0000000000020000 (128KB) 0xFFFFE0004BF6B420 0xFFFFC000FC31E6B0 P0 Mem 0x0000000000060000 (384KB) 0xFFFFE0004F8DA490 0xFFFFC000FBFCDD00 P0 Mem 0x0000000000016000 (88KB) 0xFFFFE0004D4EE770 0xFFFFC00105470E00 P0 Mem 0x0000000000016000 (88KB) Total App References: 0x0000000001705000 (23MB) Total Mem References: 0x00000000083E7000 (131MB)

That was in-game idle no AI. Can you actually profile your system before making a statement? People are conditioned that throwing more CPU or GPU at something it is going to perform better. The thread-catchup is also on GPU time. There is too much data to post. A fair few of the DMA calls are taking a long time, unnecessarily long time.

ArmA 3 is multi-threaded but in an extremely light way. May I direct you towards the following data recorded from Windows Performance recorder and Windows performance analyser and GPU-view. ArmA 3 is literally waiting for hundreds of threads to catch up no wonder we have crap performance... Thread timeline data: 10 threads doing nearly nothing? Anyone say why? I believe it is exactly what the developers said ArmA 3 is predominantly dependent on single-threads and puts the game on the fastest core. But? Couldn't bohemia enhance game-performance by using SSE 4.x and AVX extensions? Most CPU's come with SSE 4.x and CMT16 / AMD equivlents. And the GPU is doing nothing almost.... with arma 3... http://msdn.microsoft.com/en-us/library/windows/hardware/hh162945.aspx Data Dump Requested by Dwarden. GPU-AND-CPU-TRACE-DATA.7z

I join an ArmA 3 server normally etc. While monitoring in windows service panel. Ok BEService starts normally after I disconnect from that server I get subsequent "BattlEye Client not responding" Now my router is a DGND 3700v2 and my AV I don't think has any part in this it only started happening after the other day with repeated "BattlEye kicked Corrupted data 0000003#" Anyone else having this issue. # tested the MTU size # tested with allowed firewall rules # test with manual starting of battlEye with both SC command's and NET commands # check my firewall AV. I have pretty much exhausted all possibilities including cache verification and deleting and redownloading battlEye repeatedly # Attempted running as Administrator Also side note it happening to someone else, I have no idea what this is, but could it potentially be related to the gutting of GameSpy technology? I am not using the Dev build but just wondering, Also that doesn't help me much it is happening to other people. My system is not Overclocked either. This is actually happening on official BI servers Zeus DLC ones. And every other server

http://lifehacker.com/a-beginners-introduction-to-overclocking-your-intel-pr-5580998 http://www.techradar.com/au/news/computing-components/processors/beginner-s-guide-to-overclocking-1040234 http://www.pcstats.com/articleview.cfm?articleID=1804 I personally like how to geek http://www.howtogeek.com/165064/what-is-overclocking-the-absolute-beginners-guide-to-understanding-how-geeks-speed-up-their-pcs/ I personally do not overclock unless the math sits where I'd like it to be High-volume water-pumps and vapor-condensation chamber coolers. You could just wait for the new Intel I7-4970k I am probably going to go for the I7-4970k which is base clocked at 4.00Ghz http://ark.intel.com/products/80807/Intel-Core-i7-4790K-Processor-8M-Cache-up-to-4_40-GHz Might be considering an I7-4xxx (X edition)? (Haswell-E)

Just a temp test server I actually hosted the Game and the Server on the same system... It's just an I5-2400 3.1Ghz (Turbo 3.5Ghz) I use the test server for diagnostic purposes for both game problems and game network related issues. Also as far as I know, the headless client could potentially be a bottleneck. I think they were 256 MaxMsgSend MinBandwidth default and maxBandwidth 24000 MaxNon 1024 MaxGuaranteed 256 - 512. As I said play with them a bit. Find out what works.

You'd put something realistic. What it does is it "calculates" or estimates how much bandwidth the server has available. The more accurate you are to an estimation you make the less work the server has to do. MaxBandwidth based on what I see your speedtest clearly running either a Cable modem with DOCSIS 3.0 or Fibreoptic connection I'd set it to around 5 to 7MB/s which is 58720256bits

https://community.bistudio.com/wiki/basic.cfg Basically ArmA 3 sends a number of "messages to a client" the theory in this is if you can, you can reduce the number of messages per simulation frame. So ArmA 3 is very dependent on the server. MaxSizeGuaranteed is for non-repeative updates such as gun-fire and projectile updates on the other hand MaxSizeNonGuaranteed is for messages from repetitive updates. What ArmA 3 does is it takes the MaxNon and Max packs it into a "packet (aggregate messages)" then sends it to the client. The rate of those updates and the size of those messages within each update so you have a set of. I've mucked around with 128 updates to 512updates all the way upto 1024updates also if you increase the value of the updates the updates can't be faster than the MaxMsg's so if you have MaxSizeNon = 1024bytes; you can not use update rates faster than the message size. MaxSize and MaxSizeNon they are 512bytes and 256byts they are then packed into aggregate messages which is the 512bytes + 256bytes without the headers accounting to 768bytes * 128 updates per simulation cycle also known as "tick on the server side" in theory smaller faster packets are better. Gives the client the necessary time to digest them. But it varies play with the values a bit just don't go over-board because the more simulation "updates" (ticks) means more load on the server MinBandwidth well for your connection of 75MB down doesn't matter primary concern for a server is the upstream bandwidth, bandwidth just refers to how much data can be sent. In the case of your 20MB upstream the Minbandwidth you would probably use is much more than a server with upload of 1024kbps which the recommended bit-value for that is 768,000bits which is equivalent to 98.0Kbps your server is nearly 12 - 14 times that of the default value. now your server has a lot wider ability. I recommend based on lets say a ratio 98.8 * 14 = 1372KBytes * 1000 * 8 = 10976000bits. Which approximates to a 1MB/s upload speed. Which takes approximately 50% of your total upload at 18.90Mbps (bits) * 8 = 2.3625MB/s upstream. Higher the bandwidth the more aggregated messages you can send to the client. But beware sometimes the packets will get dropped resulting in desync play with the values a bit. And about the headless client just remember the bandwidth required and network updates will probably dynamically change as the headless client pretty much has no limit. But it is limited by the servers network parameters themselves. Furthermore the headless client is for both scripts and AI. In the event you have more scripts running and more AI don't you think you are going to need either more or less messages and larger or smaller packet sizes? Or larger or smaller bandwidths? P.S: 2097152000 for a bit-rate at MaxBandwdith is way too high. If you want to get a gauge on how long it takes to execute an AI spawn command you can use BIS_fnc_codePerformance

I was right network parameters can severely effect frame-rate it appears you need to adjust the network bandwith etc according to your servers upload capacity. Now AI with a headless client running you will need A LOT of bandwidth allocated. Why do I say this? Really it's common sense, even though scripts / AI run on the server or client side you still need to send aggregated message updates for each unit or each script more units means more bandwidth if the AI and scripts are consuming more bandwidth than is available to the player it results in the servers FPS(tick) slowing down which slows down the clients. "Parameters" MaxMsgSend=64; MaxSizeGuaranteed=512; MaxSizeNonguaranteed=512; MinBandwidth=24000; MaxBandwidth=480000; MinErrorToSend=0.001; MinErrorToSendNear=0.01; "===========AI SERVER TEST SETTINGS===========" "**** FPS LIMIT ON" "**** HEADLESSON = false" "**** FPSLIMIT = 45" "**** TIME PER UNIT = 0.1" "**** AI PER BATCH = 25" "**** BATCH TIME = 15" "**** MAX TOTAL AI = 600" "=============================================" "** Fps = 46 ::: FpsMin = 43 ::: time = 19 ::: _aicount = 25" "** Fps = 46 ::: FpsMin = 43 ::: time = 38 ::: _aicount = 50" "** Fps = 45 ::: FpsMin = 43 ::: time = 56 ::: _aicount = 75" "** Fps = 46 ::: FpsMin = 42 ::: time = 75 ::: _aicount = 100" "** Fps = 44 ::: FpsMin = 23 ::: time = 93 ::: _aicount = 125" "** Fps = 46 ::: FpsMin = 38 ::: time = 112 ::: _aicount = 150" "** Fps = 45 ::: FpsMin = 40 ::: time = 131 ::: _aicount = 175" "** Fps = 46 ::: FpsMin = 42 ::: time = 149 ::: _aicount = 200" "** Fps = 46 ::: FpsMin = 42 ::: time = 167 ::: _aicount = 225" "** Fps = 47 ::: FpsMin = 27 ::: time = 186 ::: _aicount = 250" "** Fps = 48 ::: FpsMin = 42 ::: time = 204 ::: _aicount = 275" "** Fps = 47 ::: FpsMin = 29 ::: time = 223 ::: _aicount = 300" "** Fps = 48 ::: FpsMin = 42 ::: time = 241 ::: _aicount = 325" "** Fps = 48 ::: FpsMin = 43 ::: time = 260 ::: _aicount = 350" "** Fps = 48 ::: FpsMin = 43 ::: time = 278 ::: _aicount = 375" "** Fps = 48 ::: FpsMin = 43 ::: time = 297 ::: _aicount = 400" "** Fps = 46 ::: FpsMin = 36 ::: time = 316 ::: _aicount = 425" "** Fps = 35 ::: FpsMin = 24 ::: time = 335 ::: _aicount = 450" "** Fps = 44 ::: FpsMin = 40 ::: time = 354 ::: _aicount = 475" "Random Network parameters active" "===========AI SERVER TEST SETTINGS===========" "**** FPS LIMIT ON" "**** HEADLESSON = false" "**** FPSLIMIT = 45" "**** TIME PER UNIT = 0.1" "**** AI PER BATCH = 25" "**** BATCH TIME = 15" "**** MAX TOTAL AI = 500" "=============================================" "** Fps = 46 ::: FpsMin = 40 ::: time = 19 ::: _aicount = 25" "** Fps = 46 ::: FpsMin = 43 ::: time = 38 ::: _aicount = 50" "** Fps = 46 ::: FpsMin = 43 ::: time = 56 ::: _aicount = 75" "** Fps = 45 ::: FpsMin = 42 ::: time = 75 ::: _aicount = 100" "** Fps = 46 ::: FpsMin = 32 ::: time = 93 ::: _aicount = 125" "** Fps = 46 ::: FpsMin = 38 ::: time = 112 ::: _aicount = 150" "** Fps = 46 ::: FpsMin = 32 ::: time = 131 ::: _aicount = 175" "** Fps = 46 ::: FpsMin = 33 ::: time = 149 ::: _aicount = 200" "** Fps = 46 ::: FpsMin = 40 ::: time = 168 ::: _aicount = 225" "** Fps = 47 ::: FpsMin = 37 ::: time = 186 ::: _aicount = 250" "** Fps = 48 ::: FpsMin = 42 ::: time = 205 ::: _aicount = 275" "** Fps = 48 ::: FpsMin = 38 ::: time = 223 ::: _aicount = 300" "** Fps = 47 ::: FpsMin = 32 ::: time = 242 ::: _aicount = 325" "** Fps = 47 ::: FpsMin = 37 ::: time = 260 ::: _aicount = 350" "** Fps = 47 ::: FpsMin = 43 ::: time = 279 ::: _aicount = 375" "** Fps = 48 ::: FpsMin = 45 ::: time = 297 ::: _aicount = 400" "** Fps = 36 ::: FpsMin = 29 ::: time = 316 ::: _aicount = 425" "** Fps = 42 ::: FpsMin = 29 ::: time = 342 ::: _aicount = 450" "** Fps = 30 ::: FpsMin = 26 ::: time = 361 ::: _aicount = 475" "** Fps = 39 ::: FpsMin = 31 ::: time = 388 ::: _aicount = 500" There appear to be less frame-rate flux with smaller aggregate simulation messages and higher bandwidth

There is another thing you can try. Network performance tuning. https://community.bistudio.com/wiki/basic.cfg Plenty of parameters to play with here. MinBandwidth=<bottom_limit>; Bandwidth the server is guaranteed to have (in bps). This value helps server to estimate bandwidth available. Increasing it to too optimistic values can increase lag and CPU load, as too many messages will be sent but discarded. Default: 131072 Just some advice network speed degrades depending on what medium it travels through to how often it is re-routed by routers. You've got ALL the tools you'll ever need to make a brilliant server. Just need to think it through if you value the mission enough.

Again MikeTim try overclocking a single core and get back to me overclock Core 0 which on your AMD are number cores 0 - 5 overclock number 0. More details would be helpful I need that Video-card trace.. I need a CPU trace. e.g Core usage window sysinternals process explorer will give me that. There is a way around your possible memory bandwidth issue. get a Hyper-Transport cable http://www.hypertransport.org/default.cfm?page=HTConnectorsAndCables Basically it makes the system talk through the HT-bus to the bridge (south and north) with much higher bit-rate but lower bit-width Which "in thoery" over-comes the limitations of an FSB running at 64bit-width. http://www.amd.com/en-us/products/processors/desktop/phenom-ii# All I can say is there is a bottleneck somewhere but without proper diagnostics I can't help very much.

Unable to get my public IP address So I am guessing maybe the battlEye initialisation starts when getting a heartbeat from the steam server and when refreshing the steam server list and no "stop refresh button" it locks up the communication between the client and the server. Which results in a BE stopped responding Edit: Nope ok I tried some port-forwarding think it might be my router I opened the battleye port and it's respective server address. It turns out I am getting NO heartbeats from BE at all. I have tested with an open NAT even nope no heartbeats to IP 81.0.236.111 (BattlEye)

No mine is I can join 1 server it initialises and starts BattlEye fine then any additional attempts at connecting results in the server not starting I am monitoring this with windows service manager. And even attempted because doing this has worked on Punkbuster which is sending a local "restart command" via SC to the service

HBAO it's a GPU based ambient occlusion shader, but in reality it doesn't mean much. All it does is "approximate light bouncing" and softens shadows and surfaces occluded from the light. I still need you to do a trace of each GPU engines. Your GPU is more than sufficient for your CPU but again a GPU usage trace using windows sysinternals will give me a better idea of whats happening also if you can give a CPU trace if your CPU is hovering at around 40 - 60% while playing it is safe to say your GPU could be pushed further. Although if your GPU is at 100% on a single "compute engine" this is the divisions of processing cores on the die, then the bottleneck lays somewhere else. Namely it could be not your GPU but the memory clock or the bitwidth interface. The bitwidth and memory bandwidth are primary determiners for performance. Let me give you a bit more indepth. The GPU is running at 100% on Engine 0 the reason for that is because Engine 0 only has enough work from the memory to work on engine 0 if there was more work, the other core compute engines would start to see usage. Get the picture? Object Quality is the one you want set it to "Low" in the ArmA3.cfg found in your "Documents" -> "Other Profiles" in your other profiles it will be "Name.ArmA3.cfg" whatever it's name is you can manually drop ArmA 3's "SceneComplexity" to 100,000 objects and read lock it by right clicking on it and clicking the "tick box" "read only" beware after this any changes you make to that account will only show through after you "un read lock it" ArmA 3 is multi-threaded but all if not every video-game is "by technical standards" is single threaded. ArmA 3 runs it's main thread on the highest clock core. Then runs the other sub-threads on the other cores. if the main thread starts to be bogged down for example with too much work AI processing, view distance etc. the sub-threads which are the texture rendering, geometry and file-ops will have to come down to the speed of the slowest core. This results in frame-rate drops. Overclocking a single core is quite simple you need a utility that allows you to control the FTG bus multiplier this is what your CPU clock is based on the FTG generates a frequency clock at the CMOS of 4.768Mhz to keep basic system time this is then sent to the FTG(Frequency Timing generator) to the bus multiplier the bus multiplier of say for your 2.9Ghz AMD 29.0 * 100Mhz = 2.9Ghz you can hopefully with your motherboard's overclocking software change this multiplier. from 29.0* to 38.0* or even 40.0* but beware constant overclocks that are running at high frequencies constantly result in more heat build up and shorten the life of components on the motherboard and in the CPU. Also you require to adjust the voltage of the CPU in small increments, the CPU at higher clock speeds requires more voltage to run at higher clock speeds, I recemmend stepping the voltage up if you get a BSOD by 0.001 - 0.005volts till you get a stable system. DO NOT go over the thermal IHS threshold. Which for you is 62*C An additional question do you have DDR2 or DDR3 running? If you are running DDR2 are you able to get the BIOS update that allows 1333Mhz DDR3 ?

Drop your Object render complexity to 100,000 vertices / objects or tweak this artificially, then read-lock it. I've set my object complexity to 100,000 seems like the only thing you can do without overloading your GPU. Then you can go crazy with setting up Textures etc. Object and vertice complexity also known as "object quality" Ultra is 1,000,000 objects in the scene and render further ahead of the player, which results in more CPU / GPU load. Although you will experience "pop-in" it is the only real way to avoid overloading the system. Your GTX 560 TI with it's 256bit memory interface has almost double the bandwidth mine has 128GB/s vs 80Gb/s but I've done some considerable messing around even attempted to use Positive Texture Biasing. Adds more aliasing but you can compensate etc for it. Also your 100% usage isn't true 100% thats telling you about the single compute engine DirectCompute. Is doing your video-card like mine has about 12 computing engines. Often ArmA 3 will hammer the hell out of engine 0 or 1. To get a better picture of what your GPU is really doing download and run http://technet.microsoft.com/en-au/sysinternals/bb896653.aspx Top of the interface you will see 5 histogram traces click them goto the GPU tab goto GPU and tick all "measure compute engines" You'll notice which engines are active and which are not. But my advice: Overclock the GPU first your AMD's CPU has the raw clock speed needed to run that GPU at higher clock rates.These parameters on the GPU, the memory clock and the gpu-shader clock. The memory clock quite often predicts performance overall. Your video-card at 1110Mhz or 950Mhz If your memory can pump the data fast enough then the clock speed of the GPU does not matter because the GPU doesn't just have a single core. It has multiple cores running at those frequencies I believe the relationship is if your memory can pump-out more data then the GPU will assign more data to each of the cores. Thereby increasing the GPU's overall usage. See I have a GTX 650 OC 2GB now the GPU shader clock itself is at 1110Mhz but the memory bandwidth just isn't there. In your instance overclocking the GPU should have quite a large effect due to the wider memory bitwidth interface. Additionally: If you are going to overclock your CPU overclock a "single core" Due to ArmA 3 running on 1 core / 1 thread the main thread is what matters the most and ArmA 3 benefits from a raw clock speed on a single core, and any sub-threads won't be waiting for the main thread while the other assigned threads on the cores don't jump ahead. Overclock a single core and allow dynamic processor clock on the rest of the cores but not at the same clock speed as the primary single thread core. http://www.tomshardware.com/reviews/thg-graphics-card-buyers-guide,915-8.html Myths: http://www.tomshardware.com/reviews/graphics-card-myths,3694-5.html "Overclocking always yields performance benefits": http://www.tomshardware.com/reviews/graphics-card-myths,3694-9.html

AI do have wallhacks and they do track targets through walls... http://imgur.com/nDn3IaW

Bohemia Provides us the tools to make excellent missions whether we want to use them is our choice. Just a few examples include. ArmA 3's buildin Garbage collection function BIS_fnc_GC; AI-render distance management etc. People are expecting too much from the game in "giant AI fights" better management of a mission is the key better design strategies is the key. And avoidance of things like functionception. With over 800 lines of code per function. On a side note I found the data needed fred41 it appears while ArmA 3 is running it's sort of random how often the cache is flushed. Anywhere from 2 cache flushes to 90 cache flushes, per second. Windows comes with an extensive performance collection toolkit "Performance Monitor" http://imgur.com/QwOotaz

http://forums.bistudio.com/showthread.php?178133-Speeding-up-time-in-game-magically-makes-those-graphic-fps-issues-no-problem/page5 It turns out ruhtraeal that we have already hit Amadahls law from what Mike says in that page. As ArmA 3's primary thread loop begins to become bogged down because it is waiting for sub-loops (AI) and vice versa to catchup. Thereby forcing the rest of the threads to throttle-back. According to a discussion I had with dwarden. ArmA 3 benefits the most from not a "total overclock" but a singular core overclock. This means if you have the fastest core running ArmA 3's primary thread which I hope if you overclocked it ArmA 3 would just put the main thread on it. So in theory the rest of the game shouldn't slow down. And memory addresing what do you mean by that? The de-allocation / re-allocation of memory? Or hardware related issues as well? Such as the type of memory addressing a CPU within the cache uses e.g full-associative, set-associative or direct mappped? Or the primary motherboard mounted DIMM chips which run exceptionally slow and have an accessing only 1% of the time for all the L1,L2 and L3 caches? That as far as I know from a book that I am reading that is what happens "Upgrading and Repairing PC's 21st edition by Scott Mueller" Yes I do say a lot of video-games waste a lot of computing power. In the sense of the stream-processors. Games rely on a lot of "real-time factors" Such as Raw clock speed,memory-bitwidth-interface,shader core count, and compute engine divisions, TMU's and ROP's , memory clock etc. But a large percentage of the CUDA cores or stream cores / unified shader's go to waste. Not only this but as explained by Mike if the server is bogged down and the client is not the frame-rates to the client will be limited. The ONLY real solution to coding missions for ArmA 3 is to get smart with AI management avoid, overloading the scene, don't write functions that depend on other functions too much as this will open more threads then call on more threads which only results in more bog down etc. I mean how many people are running Altis Life *shudders* functionception. Functions as stated are a "non-scheduled envirnoment" meaning execute this code as fast as possible negating anything another thing is running scheduled means it is called on a stack basis rather than a best effort basis. Personally I think Bohemia does pretty damn well for what tools they've got. And again relating to your comment about Amahdals law we hit that long ago. Why do you think AMD decided to go for a heterogeneous core construction for their new CPU's? Hybrids between GPU and CPU. http://www.extremetech.com/computing/116561-the-death-of-cpu-scaling-from-one-core-to-many-and-why-were-still-stuck That explains it well enough. That games being written currently are purely unable to take FULL advantage of a multicore platform in parallel processing. BF3 was starting to catchup, Bohemia might need to as well so maybe you are right ruhtrael that they do need to re-think their game engine but heres a question? Not many people are programming highly-parallel applications, who foots the bill? I remember when I was about 13 they were talking about the buzz around CUDA technology and the count of stream-processors they've been increasing that sort of computing I have only even seen reach close to full parallel capability is Nvidia Tesla scientific Computing systems because they are dependent on money and a lot of it drug companies rely on such simulations and even chemistry. Games on the other hand do not have the capability top use the 3468 cores provided by a Tesla GPU it will be more likely to use it if both the game and the system is configured for multi-core usage. E.g a system running a Dual-processor configuration. And non-SLI bridged video-cards SLI is a bottleneck through and through. So is Crossfire.

If optimisation was an issue at the memory operations level then why do some people experience problems and others do not? Although I do agree a histogram trace of memory operations I notice a lot of peaks on re-write related to ArmA 3. Although I do wish I could find a cache analysis program. But lets not forget things interesting tidbit I have brought up numerous times if you look at the general compute architecture of video-cards namely my GTX 650 OC 2GB consists of 348Unified shader cores 99% of the time the game is using compute engine number 0 the other what? 11 are sitting idle doing nothing? When compared on metro-lastlight on someone else with a GTX 780 he noticed only Compute Engines 0 - 3 were doing any work. I am starting to think A LOT and I mean A LOT of computing power is going to complete waste. See the image below to see just how much is going to waste. http://imgur.com/dVtacIN @ruhtrael I think we should stop speculating whats going on under the engine...and actually work out the real problem. As stated by a lot of the Bohemia mods we don't have access to the source code and we don't know what issues the game-engine suffers. Just keep providing feedback thats all we can do. Very useful tools for performance Analysis (Beware A LOT of information to take in):http://technet.microsoft.com/en-us/sysinternals/bb842062 PS: Mantle is wretched. Also Bohemias excuse is the map is big... Unigine Valley is big... 64,000,0000 Sqaure meters? Sure it's a benchmark but it makes you wonder.... look at Unigine being used in flight simulators definitely rivals Bohemias engine. Independent polygonal movement is the impressive part watching grass behave like real grass.

Lets step back and review this subject from a "realistic" point of view. Optimisation does not necessarily mean "more performance" Watch_Dogs is top of it's range. But as stated by multiple Bohemia developers "improving performance is a complex issue" multi-threading is not some "miraculous" solution to all problems relating to performance. Gamasutra makes very clear the top 10 optimisation myths one of them "games don't do multi-threading" and "Using more cores is equal to better performance" Lets face it we've seen this type of problem in the past repeating. Mario 64 had bad frames, there are so many games I can recall having a poor frame-rate it is not funny. Lets stop simplifying everything to the degree it becomes too simple resulting in us not looking at the "actual" issues an encompassing generalisation of "It's the game engine" is not exactly fair thats similar to saying computers that have a higher clock speed are faster which is not necessarily the case. Myth 4: Every Optimization Yields Some Performance Gain Lets look at multi-threading from a different perspective you have an operation going on in the game lets say it's ArmA 3's AI running on the FSM files now when that begins to execute because the FSM-execution VM is multi-threaded creates a thread for that process. Now if this thread is then talking to internal sub-engine threads and the engine threads or the process are running slower the CPU's cores will run to the slowest core. Because multi-threading and parallelism still comes down to data-serialisation by which even if you have multiple programs executing on different cores after the threads execution processes are done they are again converted to a serial data form rather than parallel. "Thread 1" -> One piece of instructions "Thread 2" -> Two pieces of instructions "Thread 3" -> Three pieces of instrictions Finished instruction "Thread 1" AND "Thread 2" AND "Thread 3" Re-writing an engine can potentially yield more problems. Watchdogs for example Disrupt engine based off nothing but itself. Scales poorly across GPU and fails to run at more than 30 frames the quote from a games review site "The game is in a wretched state" Sure it uses Nvidias awesome things like Nvidia GI, and Nvidia HBAO+ etc. But large amounts of graphical fidelity at the cost of performance. Not a great trade off.

http://www.gamasutra.com/view/feature/130296/the_top_10_myths_of_video_game_.php?print=1

It appears models in ArmA 3 are either fighting for the Vertex buffer or it is any of the other buffers,Z,Back,Front etc. Shimmering on grass and objects in the distance including rocks, houses, Kavala Castle is most noticeable, as such could this if the game is rendering well ahead of your client be causing "over-rendering" where it shouldn't? There is also a noticeable issue with the grass models no matter what detail level they still shimmer like an oil-painting. Vote up this if you have this issue. http://feedback.arma3.com/view.php?id=19063 Also if you get Nvidia Inspector and goto the ArmA 3 profile. They appear to have a note there: Some objects render at wrong depth. Some objects render incorrectly.