qwertz

Hi, I have found the following oddity in my RTP, and some information that might explain why A3 is not using all available Video Memory (in my case, maxing out at approx. 3GB Vram). Background: I have a Geforce Titan with 6 GB of Vram, and 32 GB of system RAM, running Windows 8.1 x64. In the RTP file, the engine reports 3072 MB of Vram and 1024 MB of shared system memory: Now, I have found in the Nvidia driver documentation that some APIs that report total available graphic memory (TAG) are using 32 Bits instead of 64 bits, which might lead to a limit to a total of 4 GB - this would be consistent with the 3072 + 1024 MB as reported in the RTP. Questions: 1) can someone with > =4GB of video memory confirm that they are also limited to 3072MB of dedicated video memory? 2) Is there any way around this limitation (-> Bohemia ?) :cheers:

I got to say - I start to love this threat, especially with all the completely clueless statements of "mbaxter", who does not seem to realize how bad he is doing as a defense advocate for the lost case of A3L - this is getting increasingly bizarre by the day. BI is apparently not going to do anything - meh, who would have thought. In case I missed it - has anyone already informed the NL tax authorities? I mean, this law abiding A3L community is surely reporting all their revenues properly, and if not, it would be only honorable if someone would help them staying on the righteous path. Heck, I might just do that myself, just for the giggles. :)

Yep, i saw this as well. They are mocking BI.

Dear Mike Baxter, just to accurately understand this: Currently, donations will fast-track applications that have already been handed in, but you are currently not accepting any new applications (donation or no donation) - is that correct? Thanks for clarification!

I am certain that fully reading and processing the content of this thread and associated threads (as opposed to merely glancing over it) would swiflty clear up your confusion.

rxnxr23 - with all due respect, while I agree that the legal route is most likely not advisable, as someone who actually went to law school, I have to tell you that (based upon the above) you know very little about this subject.

Me thinks, that there are now only two ways how this might play out: 1) BIS continues to be passive: Some content creators might (or might not) try to protect their rights by mobilizing the community (ineffective), complaining with 3rd party services such as paypal (probably ineffective), or taking legal action (probably prohobitive from a cost perspective). All in all, it is left to the affected content creators to individually identify & battle percieved violations of their rights. 2) BIS is getting active to enforce their own rules: BIS would need to swiftly investigate & evaluate the claimed violations, and impose whatever consequences (if any) arise in a transparent fashion, so that there will be legal certainty about any similar cases in the future. Case 2, independent of the outcome in this particular case, is certainly preferable for any community which relies on the enthusiasm and work of their constituents. I hope BIS agrees with this, and shows decisive activity soon.

Hi kju, while I am largely retired from ArmA for quite a while now, I still remember the great work that you have put into AAS back in the ArmA 2 days, and seeing that you are still contibuting so massively to the community, I have signed up for patreon to give back at least a little. I can totally understand your motives, and hope you can make it work for you - the ArmA community would lose a lot if you would have to move on... Keep up the good great work !!! :clap: PS: Seeing that AiA is such a popular project, if everyone who uses it would just give $1-2 per month, this would be a non-issue. Think about it! :)

Yep, I had the same issue - as a quick fix, I added a "Request Patrol" function to the HQ action menu, which spawns a capable 8-strong squad patroling the HQ. -> PM me for file, if interested. :cheers:

Your CPU is great for multi-threaded workloads, but A3 [A2,A1,...] requires raw single-thread muscle, where your CPU is slower than a Celeron G540 (source). There might be some patch in the future optimizing overall A3 performance, but your CPU will still be a bottleneck, comparatively.

hey Fabio, I don't want to start a side discussion here, but Passmark does not seem to use a whole lot of special CPU extensions, most of the tests are basic numbercrunching: http://www.cpubenchmark.net/cpu_test_info.html

That is incorrect. A3 (in fact, all ArmA versions) are extremely CPU bound for game standards. Different Games, different bottlenecks. Look at the data.

Trying to be constructive here... Lets look at the pics: 1) The screenshots show a CPU temp of 82C/84C. If I remember correctly, the max temp for this CPU model was ~71C before throttling kicks in, severely degrading the performance. Try to keep it below 65C (not sure whether it makes any sense to invest money in a new cooling solution for this old hardware, though - up to you). 2) In the first pic, the GPU shows only 9% load, so thats another hint your CPU is not up top the task. 9% means that the GPU is not doing much and is really bored waiting for the CPU. 3) In the second pic, the CPU load is at 91%. Thats pretty much as high as it can possibly get (you rarely hit 100% with any game). Again, your CPU is bottlenecking. 3) In pic one, FPS = 30 (exactly). Have you checked whether Vertical Sync is switched off (both in the game as well as in the Nvidia contol panel)? 4) You are meeting the minimum requirements, and the game runs. No broken promises here. Minimum specs just mean that you can expect a game to run at low fidelity and frame rates, as is the case here. As said before, it is probably not what you want to hear, but in your specific case the problem is clearly the outdated CPU - the best code in the world can not change that you only have approx. 25-30% of the CPU firepower of a modern chip (which does not guarantee smooth frame rates in A3, as you rightly pointed out, but thats a completely different story and problem ). http://www.cpubenchmark.net/cpu.php?cpu=Intel+Core2+Quad+Q6600+%40+2.40GHz Best of luck with your machine anyway! PS: I don't have any serious performance problems, proving that this is NOT a universal problem (only) related to bad code. A3 is extremely hungry for raw CPU performance, as was the case with A2, A1 etc.

THIS THREAD IS CONTINUING THE "RAMDISK" THREAD - PLEASE CONTINUE THE RAMDISK DISCUSSION HERE! Original thread: http://forums.bistudio.com/showthread.php?t=88388 _________________________________________________________________ Update 19 Oct 2009 I have pimped my analysis tool a little so that everyone can download and use it to easily analyze his/her own ArmA 2 disk performance. I am not a programmer so this is one large Excel file. It includes all instructions, and the process is rather simple (read the instructions carefully though). If you use it, It would be great if you guys would share the results here in the forum so we can all learn more. Here's the download link to the ArmA_2_IO_Analysis_v0.22.zip file (now version 0.22, should work with everyone's data now): ArmA_2_IO_Analysis_v0.22.zip Please let me know what you think, i.e. if there are any problems with the tool. ___________________________________________________________________ OK guys, here's the results of a few hours of analysis (I will just post them and comment later/tomorrow in detail) - very interesting findings: Arma does not use file caching - period. This means all the tools that are advertising to optimize the windows cache are useless for our purpose. On the other hand, it means that Arma is really 100% streaming the content. Because as a 32 bit app it can only address 2GB max (and I have yet to see it use more than 1GB), with >9GB of game assets, it means that there must be a LOT of disk activity. Lets have a closer look: This is 3 x the same data, sorted (1) by PBO name (2) by MB/s per PBO and (3) by total number of read I/Os per PBO. You can use the two tables in the middle and on the right to see which PBO's you should prioritize when you have limited RAM available for a RAMdisk - just look at the "FS (MB) cum.(ulated)" column. Also, note that my 6 minutes of gameplay left some PBOs completely untouched - this alone saves 1.7GB, but might be caused by the rather short game play time for the dataset. This dataset is based upon 6 minutes of gameplay, with ProcMon capturing all file activity in the ArmA 2 folder (for this exercise, the ArmA 2 folder was on my 2 x Velociraptor RAID0 disk array, not on the RAMdrive). As you can see, ProcMon recorded over 10,000 read events, totalling ~1GB of data reads in 360 seconds :eek:. This is mostly "random read" activity - wait a moment - hard disks are not very good at random read - this might get interesting. Here is another look at the data, now on the 360 seconds timeline - and this is the key to understanding why we have stutter with HDDs but not with RAMdisks: On average, ArmA 2 creates a load of 30 IOPS and reads 2.9 MB/s. This might sound harmless, but as the graph shows, the distribution of I/Os is not at all even - it shows heavy spiking ! As a reference, this is what a fast HDD (Velociraptor) is capable of: As you can see, in random read the fastes consumer HDD is capable of 50-141 IOPS, and 0.07-50.00 MB/s (mind you, your average 7200 rpm HDD is way slower). What is more important is that as you can see above, the average I/O size across all reads recoreded is 97 KB. The mighty Velociraptor is somewhere between 50 and 127 IOPS for this I/O size. So, the spikes on the IOPS graph are definitely saturating the HDD, causing stutter. But it gets worse. The 97k average I/O size is not evently spread out on the timeline, either. As you can see on the graph above, it oscillates between a few KB to up to 1000 KB, and many times it dips into the 200k and bigger numbers. At these I/O chunk sizes, even a single Velociraptor can not deliver the 50+ Iops and 10+ MB/s that ArmA 2 is churning through !! This is what causes the stutter - ArmA 2 simply oversaturates the average hard disk subsystem. And this is why a RAMdisk helps so much in increasing the smoothness of the game! This also means that this data is not reflective of what the real I/O need for ArmA 2 is - without the HDDs bottlenecking, we would see higher numbers here. I will do the same test running off the RAMdrive when I have time to verify/falsify this thesis. Also have in mind that I am still working with averages here and one-second "buckets" - there might be more extreme oscillation going on that is just not visible at this resolution. First conclusion: put ArmA 2 on the fastest disk subsystem you have. This test was run on a Veloci RAID0, and I had a lot of stutter (well, coming from my RAMdisk, that is). Even on my Vertex SSD RAID0, there is still stutter. Only the RAMdisk removed the bottleneck completely - go figure. I'm tired now, will share some more observations with you tomorrow. Best, qwertz

UPDATE: I have created a little tool that let you analyze your own ArmA 2 disk performance - please feel free to try it out and post the results here! Download: http://www.mediafire.com/download/cmxdyl5h0zn/ArmA_2_IO_Analysis_v0.22.zip Further reading (benchmark/results thread): http://forums.bistudio.com/showthread.php?t=88629 ________________________________________________________________________________________________________________ Since I have bought ARMA 2 a few month ago, I was unhappy with the performance of the game. Besides ample hardware power (i7 @ 4Ghz, 12GB DDR-12800, GTX280 Hydro Copper, 2 Vertex 120GB SSD in RAID0, etc.) I was suffering rather low frame rates and - more annoying - stutter and texture LOD trashing. I have done a crazy amount of testing to find a solution to these problems, and now have finally reached a stage where I am happy with the results, which I want to share. All these tests were done on 1920x1200 resolution (both 3d and display), and with 3000m view distance and everything on very high, and post processing off. 1) Selecting the best OS I have tried Win7 in 64bit/32bit, Vista in 64/32 bit, and XP in 64bit/32bit. In terms of performance, ARMA 2 works best with XP32 - here's the ranking (from good to bad): 1) XP 32bit 2) XP 64bit 3) Win7 64bit and 32bit (no big difference) 4) Vista 64bit and 32bit (no big difference) ARMA 2 seems to make no use of the increased capabilities of an x64 bit OS - it is a pure 32bit application. Running a 32bit application in a 64bit Windows in theory should not cause significant performance hits (thanks to WOW64), but in case of ARMA2, it does actually cause issues. This is most true for what I call the "smoothness" of the game: In 32bit, there was less stutter (i.e. if you make a 360 degree turn, it was a smooth turn without hiccups). In terms of framerates, XP beats all other Windows versions, and 32 bit comes out best. Stutter was also least apparent with both XP versions, and best with the 32 bit version. No difference was found in my testing in terms of texture/LOD trashing - in all cases, after some minutes of gameplay, textures would visibly pop when you move fast, which I found very annoying. Which leads me to my second point. 2) RAM disk I wanted to find out what the reason for the texture trashing is. Do narrow down the problem, I monitored memory and disk usage during gameplay. To make a very long story short: the hard disk is a major culprit here, as there is ~8GB of data and textures that is getting streamed as you move around the game. Both the occasional "Hiccup" as well as texture popping happen when ARMA 2 starts to stream from disk. To solve the problem, I created an 8.5 GB RAM disk with SuperSpeed RamDisk plus (there is a 14 days trial version. The reason I chose this software over others is that is can adress the memory space above 4GB on 32 bit systems, it supports auto save/load of the RamDisk so it is persistent, and supports large RamDisks). I then moved the whole ARMA 2 folder (Steam Version) into the RamDisk (please note that you have to start ARMA 2 using the arma2.exe within the moved directory. Alternatively, you can create a symlink to the folder - pls google it). The result was - for the first time - a smooth game experience. It is hard to describe, but without all the stutter and texture popping, the game reaches a new level in perceived visual quality. Everything is smooth, LOD's draw instantly, and the whole game play feels a lot more fluent. For the first time, I feel happy with the performance of ARMA 2. Let me know if you have any questions, and pls try it out yourself and share some of your results if you want ! qwertz.

Will def check it out on the weekend.

Great job on the V1.14 Toaster, have updated the server today, missions work great! Will forward you some more missions from the ArmAcalypse community for 1.15 soon.

Ati hd5870

Maybe just switch the router for another one? I had the Netgear WNDR3700 and it worked flawlessly with A2.

Before this thread gets closed because 1) you did not use a descriptive title and 2) there is a sticky for this here: http://forums.bistudio.com/showthread.php?t=72181 here's a little hint: you need a new graphics card, yours was only midrange in 2008. Check for ATI HD5870/5970 or Nvidia 480GTX :cheers: qwertz

+1. You are overpaying by 1/3rd.

+1 :)

No, AAS for OA does not need any client side addons at this stage.

Lucky you! :) However, I don't think there is a rule to it, it happens quite randomly. Before the beta that fixed it was released, I could sometimes play for days w/o crash, and then all of a sudden would crash every time.

Are you sure you are actually using the beta (no offense, but I have seen some people installing the beta and then not using the seperate beta shortcut)? Otherwise, a look at your client/server RTP files might help.