intermittent brief pauses?

Your use of terminology is confusing. I use SSD for OS and high-end HDDs for games/storage. Both/All are SATA AHCI-mode devices. I have enough space on SSD to use it temporairly for testing purpose, something I already did in past and do plan to do with DCS later.

Ah yes.. sorry! when i say sata drive i actually mean HDD.

Anyway since i put dcs on the ssd drive i no longer experience the brief pausing.

It is completely valid that a more demanding software like a realistic simulator, requiring higher magnitude of hardware, however in my research I can see many occurences where files that should be preloaded as per core default are not, and thus require storage operations even many times in one session.

Indeed some of those storage operations may not be noticable because OS "standby memory" caching kicks in, but let me explain that this is an external bonus feature and should never be relied upon by developers or users, it is absolutely a spoilment and an artificial hacky fix only in practise, that the program(game) no idea about, the game is still not managing its assets correctly, therefore technically it is the games fault, and the OS mem caching doesn't know to keep exactly those problematic assets cached.

So what do we get, confusion, min sys requrements, recommended sys requirements, its all innaccurate, because more is actually needed for the game than the appliication working set shows, part of whats needed that game's Dynamic Asset Allocation Manager is missing(some critical models/textures) is then either not loaded(allocated) or counted in the total of cached "standby memory", and that is the part that OS caches to its own liking, this cache may not retain some files at times when needed, and is also treated as "Available" RAM that is "not used", the OS only provides this bonus on-top feature and should never be relied upon, but this feature being defacto new environment it has spoiled developers because it covers up their mistakes, generally speaking, not sccusing eagle. Im not complaining in this post either, just explaining findings.

So this game as it is currently will always stutter, a lot on HDDs, no matter what fps, the system specs just determine at what quality it will stutter, but here's the catch, if you increase the "visibility range" and "preload radius" to get that better quality at a good framerate because your system can support those extra drawcalls and render load, in return you actually get more stutter because you have just increased the constant dump-load alloction area, depending on speed an direction of the aircraft to some extent.

The "camera mouse movement lag" is separate but similarly has to do with storage operations, that one will lag even if your not flying, just viewing and rotating around a completely stationary unit.

But, furthermore as I discovered it is not actually the terrain textures which are a major part of the constant dump-load cycle, to be so problematic, they can be streamed (queued too) ... It is the models and other key materials, those cannot be half-loaded, and all of them that needed but queued have to finish loading, these are critical assets and these basically freeze the engine if not present instantly, and the most notorious cases are the crash events (damage models) and the ejection sequence, these are what DAAM is mismanaging, they should never be unloaded, never be part of DAAM, static, loaded always if its parent exists or will be spawned on the map by script. More on that in future.

A high perf realism program of this caliber needs it's own memory management and not rely on the OS to fix it's shortcomings. Those individual counted for, it's still not enough, atleast for HDDs, and then its a question if its worthwhile making support for a HDD friendy DAAM type, when SSDs and NVMe are approachingmainstream use.

It is completely valid that a more demanding software like a realistic simulator, requiring higher magnitude of hardware, however in my research I can see many occurences where files that should be preloaded as per core default are not, and thus require storage operations even many times in one session.

Indeed some of those storage operations may not be noticable because OS "standby memory" caching kicks in, but let me explain that this is an external bonus feature and should never be relied upon by developers or users, it is absolutely a spoilment and an artificial hacky fix only in practise, that the program(game) no idea about, the game is still not managing its assets correctly, therefore technically it is the games fault, and the OS mem caching doesn't know to keep exactly those problematic assets cached.

 

So what do we get, confusion, min sys requrements, recommended sys requirements, its all innaccurate, because more is actually needed for the game than the appliication working set shows, part of whats needed that game's Dynamic Asset Allocation Manager is missing(some critical models/textures) is then either not loaded(allocated) or counted in the total of cached "standby memory", and that is the part that OS caches to its own liking, this cache may not retain some files at times when needed, and is also treated as "Available" RAM that is "not used", the OS only provides this bonus on-top feature and should never be relied upon, but this feature being defacto new environment it has spoiled developers because it covers up their mistakes, generally speaking, not sccusing eagle. Im not complaining in this post either, just explaining findings.

 

 

So this game as it is currently will always stutter, a lot on HDDs, no matter what fps, the system specs just determine at what quality it will stutter, but here's the catch, if you increase the "visibility range" and "preload radius" to get that better quality at a good framerate because your system can support those extra drawcalls and render load, in return you actually get more stutter because you have just increased the constant dump-load alloction area, depending on speed an direction of the aircraft to some extent.

 

The "camera mouse movement lag" is separate but similarly has to do with storage operations, that one will lag even if your not flying, just viewing and rotating around a completely stationary unit.

 

But, furthermore as I discovered it is not actually the terrain textures which are a major part of the constant dump-load cycle, to be so problematic, they can be streamed (queued too) ... It is the models and other key materials, those cannot be half-loaded, and all of them that needed but queued have to finish loading, these are critical assets and these basically freeze the engine if not present instantly, and the most notorious cases are the crash events (damage models) and the ejection sequence, these are what DAAM is mismanaging, they should never be unloaded, never be part of DAAM, static, loaded always if its parent exists or will be spawned on the map by script. More on that in future.

 

 

A high perf realism program of this caliber needs it's own memory management and not rely on the OS to fix it's shortcomings. Those individual counted for, it's still not enough, atleast for HDDs, and then its a question if its worthwhile making support for a HDD friendy DAAM type, when SSDs and NVMe are approachingmainstream use.

Thanks for your insights Wader8.

Yes, I dont DIVE into OS memory management, neither do I have the need to..and dont have the education to do so as I am no MS employee with the technical insight, nor do I work for Asus and have to deal with it as a board designer.

On the other hand, I take a gun when I go to a shooting and dont come along with a knife either. Maybe that describes it best.

It's been stated a 1k times that DCS really really benefits from SSD usage, either independant SSD for games/DCS only or even a combined usage with OS +DCS on 1 (fast) SSD. There are SSD's and SSD's !

There are systems fast enough to run DCS at 100-180fps in WQHD with rather nice settings in most of the airframes, maybe not the Ka-50 A10-C or Mi-8, but all my FC3 or WWII run anywhere between 100-180fps, buttersmooth.

It's just unrealistic that the same will happen with DDR1600 and HDD, face it, coupled with a CPU that is almost 2000MHz slower than what top end users do.

You can ask ED to reprogram DCS and implement an Oracle style mem-subsystem, yeah, it just wont happen quick, if at all.

It's rather more rewarding to look at what the user CAN DO to overcome this, and this is outlined pretty well.

May I add, I am an IT Pro and none of the srv's I make suffer from I/O bottlenecks, you just have to use the right HW to counter the apps demands. THAT you can do...or not.

Yes, the minimal system requirements were never correct imo, this game is not meant for HDDs then.

But look, here's my point, certain assets need to be loaded all the time, and the non-critical things like textures do not, as long as the current manager type properly separates and loads all the problematic assets ahead it will work guite good, and the textures are streamed in asap but queeable without the engine having to wait for them. All it will take is slightly higher RAM usage on average, piece of cake. Additionally some practically-key textures could be handled as "critical", stuff like player's cockpit, exterior, engine effects, basically player controllable units would always be fully allocated no matter what.

And yes it does take work, first better naming and sorting and optimizing the filestructure, tons of small files should be put in zip vfs, grouped and named appropriately, this would make it clearer and easier for this allocator later. Then a generated (separate utility) but manually adjusted index file would contain all the non-engine content asset filenames or filepaths and the Allocator (DAAM) behavior mode for that file. There would be several modes, i will now list my draft idea of this below:

With boot, I mean the first load screen, not engine init, but engine init shouldn't load anything beyond it's barebone core stuff and the checks it needs to do, any extra stuff needed for only init has to be read-and-dump.

Static means it's loaded in a loadscreen in one sweep, stays loaded, gets unloaded on an exit event. Not auto managed.

- boot static critical -- for assets that load at boot and never get unloaded in session

- boot static conditional -- for all assets that load at boot but are not needed out of main menu

- editor static -- new loadscreen for editor, load editor specific and first zoom level of F10 map

- editor dynamic -- the rest of F10 map zoom details streamed in without freezing viewport or GUI

- mission static critical (map specific) -- all base assets that get loaded for a mission session no matter what players or units used, but also includes assets of player's unit(weapons too, effects, sounds), will never get unloaded until mission exit (pause menu, gui, etc)

- mission static conditional -- all unit assets, works a bit different, activated depending on parent existing on map or scripted to spawn.

- mission dynamic P1 -- for map assets, sky, terrain textures with highest priority

- mission dynamic P2 -- for map assets, sky, terrain textures with secondary priority

- mission dynamic P3 -- for map assets, sky, terrain textures, with tertiary priority

-- etc

Priority is meant --> If many different dynamic assets are requested for loading in short period of time*, and get queued, the higher priority ones get to be read first.

* It is up to developers to determine the optimal duration of that "short time", how many microseconds.

( todo unit asset tree groups index)

Modificators - applied over the main index, overrides values depending on ingame circumstances/setting.

- other units dynamic (optional) -- other players or AI units assets, for lower end systems, but really just affects average RAM usage.

If filestructure is properly sorted and named, making unit asset tree lists will not be complex.

If this is solved like that, no storage will slow the engine down, so right now, what you call buttersmooth is just apparent case, technically it's still making micro-freezes.