Does DCS World benefit from more than 16GB Ram?

:thumbup:

I have been monitoring my RAM for the last few days. (appologies to the last few Msgs, I stopped reading at pg. 3)

Starting out, 2.7GB in use on a 16GB system. Gotta have background programs running. Today I finally paid for permission to fly in the Persian Gulf. My rig runs up to 15.9GB online and crashes. In single player, ( Gulf map ) She runs up to 15.9... then drops to 12 (ish) GB. My point is that where we have a 16GB total system, DCS needs all of it. I doubt our systems can operate with 0 RAM in use.

Caucus, Nevada, Normandy all run ok on 16GB total. The Gulf needs more tho. And I'm thinkin a 500GB SSD with all supporting programs on it. Vulkan sounds promising for Multipule GPU's..... wishful thinking from the owner of AMD CPU and GPU.

I don't know. I have no money to throw at this. Just thoughts.

(P.S. Nevada, Normandy, Caucus online never crash, Mission Editor Gulf map is void of additional units with exception of the AV-8B I flew)

If you have pagefile, it may slow down but it shouldn't crash. Do you have pagefile set to auto? Or sufficiently large?

My gpu is the bottleneck and cant be replaced(laptop). Will doubling my 16gb RAM allow me to push higher settings or am I screwed until I build a new system?

Thank you

Adding RAM won't do you any good in this regard. If the VRAM is the bottleneck short of running an APU build (which would also generally be a waste of money) you can't allocate additional memory resources to the GPU.

It's somewhat a bottleneck on my build - my Radeon 570 only has 4GB and its always pegged (but graphics still look good!).

A year ago you really would have been screwed but miners are rare now in the sales dept - so what kind of budget do you have for a new desktop? You can put together a decent system for pretty cheap, then upgrade in the following months to come (which is currently what I'm doing, the upgrade part). Originally I was worried about double buying some parts but it occurred to me that I could get even better performance if I build a second box to run as a server and play even single player missions as multiplayer letting the server box host the game (then my system can ignore AI calculations).

If you have a decent rig and play multiplayer in any well populated servers 32GB is almost a neccesity...Going from 16 to 32GB of RAM yielded a huge improvement for me...a big reason why I went to 64 on my latest build...as I was seeing RAM usage up in the high 20s at times..granted 64 might be a bit of overkill. 32 definitely isn't!

64GB :thumbup:

Going from 16 to 32GB of RAM yielded a huge improvement for me...a big reason why I went to 64 on my latest build...as I was seeing RAM usage up in the high 20s at times..granted 64 might be a bit of overkill

if you think 64GB is nice, you should try 128GB!

On my 16gb system DCS 2.5 is pretty much using up all memory it can, and that on the most simple instant ''takeoff'' missions. NTTR as well as Caucasus. And i can't really make heads or tails of the memory readings i get from sysinternals or the resource monitor, see attachment below. When i have nothing running except for DCS NTTR A-10c takeoff instant action mission, physical memory is filled up to 12.5gb. If i kill dcs, it drops down to 2.5gb. Thus DCS alone sucked up 10gb. But i kinda fail to see how those 10gb are represented in those sysinternals memory readings shown below.

And, i have tested all my more memory intensive games and DCS 1.5.8 legacy build as well, and none is showing this weirdly high ''working set shareable'' memory load. Working set shareable with other games including DCS 1.5.8 is something between 60 and 500mb. DCS 2.5 uses at least equal and most of the time more memory as working set shareable than working set private.

If you add up WS shareable and WS private you end up with the overall 'working set' memory usage. But this is still far from those 10gb that are emptied as soon as i close DCS.

What is actually included in private bytes (commited bytes), working set and so forth seems rather complicated as aproximated by this discussion here, especially the first answer;

https://stackoverflow.com/questions/1984186/what-is-private-bytes-virtual-bytes-working-set

''The short answer to this question is that none of these values are a reliable indicator of how much memory an executable is actually using, and none of them are really appropriate for debugging a memory leak.

Private Bytes refer to the amount of memory that the process executable has asked for - not necessarily the amount it is actually using. They are "private" because they (usually) exclude memory-mapped files (i.e. shared DLLs). But - here's the catch - they don't necessarily exclude memory allocated by those files. There is no way to tell whether a change in private bytes was due to the executable itself, or due to a linked library. Private bytes are also not exclusively physical memory; they can be paged to disk or in the standby page list (i.e. no longer in use, but not paged yet either).

Working Set refers to the total physical memory (RAM) used by the process. However, unlike private bytes, this also includes memory-mapped files and various other resources, so it's an even less accurate measurement than the private bytes. This is the same value that gets reported in Task Manager's "Mem Usage" and has been the source of endless amounts of confusion in recent years. Memory in the Working Set is "physical" in the sense that it can be addressed without a page fault; however, the standby page list is also still physically in memory but not reported in the Working Set, and this is why you might see the "Mem Usage" suddenly drop when you minimize an application.

Virtual Bytes are the total virtual address space occupied by the entire process. This is like the working set, in the sense that it includes memory-mapped files (shared DLLs), but it also includes data in the standby list and data that has already been paged out and is sitting in a pagefile on disk somewhere. The total virtual bytes used by every process on a system under heavy load will add up to significantly more memory than the machine actually has.

So the relationships are:

• Private Bytes are what your app has actually allocated, but include pagefile usage;
  
• Working Set is the non-paged Private Bytes plus memory-mapped files;
  
• Virtual Bytes are the Working Set plus paged Private Bytes and standby list.
  

There's another problem here; just as shared libraries can allocate memory inside your application module, leading to potential false positives reported in your app's Private Bytes, your application may also end up allocating memory inside the shared modules, leading to false negatives. That means it's actually possible for your application to have a memory leak that never manifests itself in the Private Bytes at all. Unlikely, but possible.

Private Bytes are a reasonable approximation of the amount of memory your executable is using and can be used to help narrow down a list of potential candidates for a memory leak; if you see the number growing and growing constantly and endlessly, you would want to check that process for a leak. This cannot, however, prove that there is or is not a leak.

One of the most effective tools for detecting/correcting memory leaks in Windows is actually Visual Studio (link goes to page on using VS for memory leaks, not the product page). Rational Purify is another possibility. Microsoft also has a more general best practices document on this subject. There are more tools listed in this previous question.

I hope this clears a few things up! Tracking down memory leaks is one of the most difficult things to do in debugging. Good luck.''

If i understand this correctly, 'working set shareable' includes memory pages

that are not DCS specific but are common to Windows and could in theory be shared with other programs and games running at the same time as well.

But what and why would DCS 2.5 load non DCS stuff like Windows libraries and such to the amount of 3-5gb? Again, i don't have any other game that shows this behaviour. And how come DCS obviously uses up 10gb of RAM when which i can't really account for in those memory readings shown below?

Does DCS World benefit from more than 16GB Ram?

each process running on windows uses the operating system and those operating system files are loaded into your process virtual memory space.

since most of this is “read only”, a smart (modern) OS can “share” these between processes and save physical RAM usage.

your process is still using the resource and it will still be counted in your process memory stats, but it is not using that much physical RAM space, just virtual space.

it’s a useful and efficient OS feature to provide better performance with less resource usage

Virtual machines are a perfect example of the above. Identical OS's can share a lot of memory on one and the same host.

But for me and my gaming rig, this is far more simple than any Hyoer-V server. I look at the overall memory usage, I can't really help it anyway but add more physical RAM and/or grand more dedicated super fast swap space, there ain't more you can do at this point. For me and for some others the answer was: "Look, it ( THE System, not DCS alone ! ) consumes more than 16-24GB at times, the 32GB are well justified"...the other side are guys that had 16GB, had some stutters and loading probs and installed another 16GB and it went away. How much more does it need ?

It may work with 16GB on selected missions and modules but I am sure, a FA18 in bad weather and 100+ objects on ground an in the air will love 32GB.

Actually, I am astound that this conversation pops up and up and up again. The answer was given over & over by dozens of well known Pilots.

Anyway, no CPU can manage 100+ objects on DCS.

I have a mission template for my Squad flights with 600+ objects running fine.

Specs below

Anyway, no CPU can manage 100+ objects on DCS.

For info, i talk about the AI...

if you think 64GB is nice, you should try 128GB!

LOL Well thank you for making me look conservative:D 128GB Damn now that my friend is overkill...but glorious I'm sure!