Worrazen

There's another separate thing I mentioned I wanted to report, but couldn't do it in time, I just have to do some other chores around the house which again includes disconnecting the PC for a few days or more. That one may be even bigger than this, but I have to give it more time so that I don't keep rewriting the posts and correcting myself, one of my bad habits :music_whistling:. I'm not sure anymore if it'll be worthwhile posting that in the same thread, while it's about the File/Disk I/O and threading, it doesn't have relation directly on the outside ... infact when I come back I'll separate the MSI Overlays guide into a more general one, there's a few paragraphs I see I misplaced and the formatting isn't the best . Sorry, not this time around, I did a general "report" on threading a weeks ago because I've seen a lot of external communities bringing up the whole single-threaded idea and while that is somewhat true it's really a different story these days and there's about 3 really busy threads as well as a bnch of Disk I/O & Memory threads so a Quad-Core CPU should be well worth the dime and it's not that bad really, it infact exceeded my expectations. Because this is primairly a "bug report" and focusing on technical details that are neceessary to have right, from what is possible from my side at least, it is not meant for everyone. The reason why it seems it's a lot is because I wrote it as a guide for fellow players who are browsing this subforum that are kinda interested but may not be willing to get too deep into or don't know where to start, it's can be a grueling job and it's not that interesting such as modding, but I thought perhaps it's not interesting because of less guides and ease of getting into it, so why not also provide some explanation from which it can help you understand this threading and the basic CPU perf counters for good. Hopefully reporting performance bugs comes with more details in the future. If one does not have interest in replicating this track/guide the only TLDR can be the description, or a long title, which I agree I should have posted as the first sentence; the DCS Disk I/O & Mem/Data Management threads* seem to be competing for CPU Time and because throttling them and allowing the main thread to have a full core all to it self seems to be getting rid of the stutters is what lead me to call the title like I did, but these threads could be interrupting something else as well, this is usually always an educated guess more than some kind of proof and definitive answer. The "Mem/Data Management" part is my latest speculation because they also seem to be active anytime there's any shuffling of most-needed textures when you're scrolling/zooming in various views or the F10 map -->> even when there are no Disk reads(activity) so it must be in my opinion right now, also managing the assets/textures/terrain objects around in RAM/VRAM, I'll show this later or in an newer thread part of where it is most relevant.

There was an interview or something that I heard in an newsletter or something, I was surprised as well.

You can turn back to 2.5.5 yourself by using the release version. Your argument would also be unacceptable because this is not unexpected to happen in Open Beta.

The loss of FPS during crowded areas is expected but it seems to be something that makes it so much bigger, it may be the occlussion culling thing that renders everything irrespective if it's being blocked or not, I was about to post new tests but I took another thing first I had been working on about threading earlier. That may mean it's also rendering the backsides and internal parts of the aircraft (gears), that is one theory.

Balance only matters for multiplayer, but even then, that's really a subjective viewpoint, server owners are supposed to limit aircraft availability to an era-timeline to replicate "balanced" environment and circumstances in their mind. Reality isn't balanced really so it's never a true balance, it's just that you would call it balance with your own meaning and context, the true description is Era/Timeline/Generation Accuracy, that's really it. The only thing devs responsibility would be is providing the tools and support (API/scripting) to separate things by Era/Timeline/Generation more easily, then there's another subjective factor of where is the separator/cut-off point for the generation, is it a gray area, or is defined, the developers may pick some arbitrary-seeming number(year) according to their research or they may follow some kind of political-economic events, well yes that makes sense, but would everyone agree? I suggest there should be profiles you could do yourself, where you could set the start and end date of each era, with the official ED profile being the one you would get out of the box. However first to support this all the aircraft, weapons, systems, units would have to be referenced in a master table to set dates in which years they're available. But you see there's another dillema, who decides from what to what year a unit or a system is available in objective terms, it's all subjective again, there could be some kind of collaborate effort to figure out some kind of a date everyone can agree with but it would take a lot of work. Just look at Syria now, they're using old MiGs, so how do you even begin to think when something is too old, it's all subjective. I think we should forget the ideas above to not do things twice, and rather have an editor that directly edits all units and weapon availability (start and end date), you would modify that in like a huge GUI page, and then make a profile (diff) out of that, just like editing controls, and call that an Era/Timeline/Generation profile and use that in a dedicated server. All you would do then is just pick one timeline for the active session, one setting for start and end date, and the system would automatically disable/enable units/systems/weapons according to that and the ERA profile you loaded if you changed anything at all from the defaults. You can discuss but the validity of the topic is questionable, it's only a valid topic between server owners and players more likely, but that is the kind of things that can be done, infrastructural support, but it's up to you to define the actual timelines.

I was just showing DCS, a day prior to announcement, to someone who doesn't really have interest in flight sims but occasionally concedes for a few hours as a showcase of some aircraft, it was a good 5 hours and I chat about DCS in general and then I mentioned: " ... and there's one called Eurofighter Typhoon, but who the heck knows when we'll get that one"

There is no smoke in the video so it can't be that. He has more than stutters, these are so big they could be called temporary freezes. Secondly try looking in Task Manager if anything else is causing spikes on CPU. If you are interested in digging this deeper and be ready for when you need it next time you could get a good performance overlay going using MSI Afterburner and RSST and set it up according to this thread https://forums.eagle.ru/showthread.php?t=267809 or similar. I could barely see the FPS in the video, it's very low quality, was that really the quality it was recorded in? Then the bitrate should be increased a bit, it was enough to get the idea tho. Keep in mind recording with software would affect the CPU and may exaggerate the problem or even create sideeffects, you would need to gauge how much does the issue change when you record the clip. Since this is Multiplayer only then you may look into network issues, you could setup to in the MSI-Afterburner/RSST overlays to show you ping and other network information. I do not have much DCS multiplayer experience tho.

Nevada Case Examples: (in progress, planning to also display CPU0 graph where only the main thread resides in "workaround affinity" cases) Latest notes: It may be more things at play, don't even need to be in cockpit and view the TGP to make some of the stutters happen. But this makes sense that the asset loading works all around even if you're not looking at it directly, so that's probably not unexpected then. Not all Disk usage spikes cause a FPS drop, right now I have no idea, it's pretty random and unexpected, it may be that some specific data causes it under specific circumstances, perhaps the initial rendering of it is costly and takes a chunk, it goes into more speculation waters from here on out, but I'm going to keep an eye on this ongoing, but without rushing to any results or conclusions. Quick Update Obviously it's about a specific component on the main thread, because you can have the thread 100% but for a different reason most likely graphics api and drivers, it'll just limit the max FPS most likely, but it won't stutter or interrupt anything, usually the main thread does a lot more as FPS increases. The reason gui locks during loading screen is probably understandable but I think with a different approach this and other such cases could be avoided in future, it's not that big of a deal tho, and now when I'm using workaround affinity, i've seen it work better and not cause any errors, it's kidna random so I can't call it. I'll look more at the terrain stutters deeper later. ------------------Update: Discovered something new with one of the special ucrtbase threads, it's a finding on it's own, but I'll post it in the same topic, quite interesting.

2: That is indeed the correct and expected result, DCS Disk I/O can use a lot of threads to load all kinds of assets. But too much threading, or rather improper or not optimized thread behavior (priority, etc) may lead to negative side effects https://forums.eagle.ru/showthread.php?p=4263080 As for HT/SMT in general, no it shouldn't help much otherwise, that's normal for DCS right now.

Reserved

----------------------------- Original Post from 2020: [WIP - OP from 2020 was reworded for more clarity, readability, less focus on the side issue, formatting and coloring for new forum system and compatability with further updates - Feb 2021] Hello Who would have thought that would ever come to a point like too much multi-threading ... unfortunately it may be so in the worlds of computers. With all the multi-threading buzz and anticipation sorrounding DCS World, this is a good example to show that multi-threading has it's particularities as well and optimizations that have to be finely tuned. I have decided to take the time and treat the community with a bit of a commentary, so this is a multi-faced forum topic that is more than just a bug report. The key ofcourse is the data for the team, but I went a step further with the explanations for the curious folks, including a good reminder for my self when and if I come back to this issue, or a similar scenario unrelated to DCS, it happens. For the average players who aren't interested it may be best to avoid most of it, if all they wish is a TLDR. While a TLDR is possible, that isn't the goal with these sorts of reports. Intro - includes test run specifics and background This is my understanding at this point in regards to what's happening here with DCS and anyone's welcome to correct me if they feel like I'm missing something or coming to a wrong conclusion. I tried to get a real take on a different machine for this one, to make extra sure it's replicated more broadly rather than on just one PC configuration. DXDIAG of both is pasted below, unfortunately it wasn't what I was hoping for, the other remote machine didn't quite show enough of this workaround working, or I made a mistake when testing, I also think it could have been due to other reasons: The CPU is weaker and it may not be able to accomodate the Main Thread's increased activity when large portions are being streamed and other things during very active scenes, even if it had a whole core for itself. It has only 16 GB RAM, however it feels that DCS did notice and adapted to that, still that means the pool size is lower and it has to perform more Disk I/O as it's trying to keep a tighter RAM budget, which is correct how the proper dynamic asset loading systems should work, except in DCS when something has to be loaded it takes so much CPU (it may be graphics/rendering related too but not going deeper on that right now) I did not record anything while testing on the secondary PC, the weaker CPU there makes that difficult to do simultaneously while trying to not interfere with the test. It may not be the amount of threads themselfs, but just because the combination of my amount of CPU cores and enough other threads that saturate all of them, people with much higher core counts may not see this issue nor require this workaround. Continuing, perhaps the default thread priority may also have something to do with it, if it's not optimal, adjusting that may help and this may be where the room for improvement could be. I haven't tried testing thread priorities in this run. The mission I used in this session/run, the numbers and claims are referring to, is a barebone flight on Caucasus map. I picked the term "barebone" meaning that it's a solo pilot plus an empty airplane free flight without any other activity on the map, the exception to the barebone is the use of TGP and MAV which is noted, so "Barebone+TGP+MAV" for example. I have mentioned for a couple of months around ED forums how I reached a sort of dead-end, because to do what I have foreseen back then, would require CPU affinity modification on a per-thread basis, without having to modify DCS files, is key memory, or otherwise interferring with the clean public client version, so that any possible workarounds or testing would be possible for the public at large without any kind of messing with the anti-cheat and authentication systems. Turns out there is a way to do it already from the outside just like I hoped for with the WIN32 API, ofcourse developers at large who make software for Windows and use it's SDK's can do this easily and it's no big deal nor anything new. In an amazing turn of events, I found out it's already been implemented for quite some time in a program that for some reason I never came across until a few days ago, well I must admit I didn't look hard enough, all the years I was into Windows tweaking, troubleshooting and optimizing. I guess the saying of "you never stop learning" is quite something that rings around us all the time. Process Hacker can do just that, without interfering with DCS (AFAIK) and this opens up many ideas what I dreamed about with many kinds of programs/games in terms of perf diagnosis and stuff, but the bigger thing is, it opens up potential for workarounds and temporary solutions. In this forum topic I explain one such possible example. -------------------------------------------------------------------------------------------------------- /////////////////////////////////////////////////////////////////////////////////////////////////////////// -------------------------------------------------------------------------------------------------------- Overview of the threads in Process Hacker: (~Q2 2020) If I would take some of the thread priorities at face value, I'd say they are suspicious and may not make sense but I don't want to make any conclusions whatsoever on that. I can see the DCS Main Thread is "Normal" while several of the data loading I/O threads are "Above Normal", given that we can agree on engine responsiveness being more important than a few textures coming in a bit late (miliseconds, etc), then those priorities should be the other way around, vice versa, if I understand what these priorities mean and do, which am not sure right now. To remind ourselfs, dynamic texture loading is suppose to be down the list of priorities, because of what I think are players priorities, seeing a higher quality texture LOD pop-in a bit later (may not even be noticable difference) is probably much much lesser of a negative impact than experiencing a stutter or more. Speed is welcome ofcourse, hence texture loader I/O is split into many threads to load many section of terrain textures and materials simultaneously, all without interfering with the gameplay, without needing to pause for another loading screen for example. Old retro games didn't need streaming back then because they just loaded everyhing in RAM in the beginning, at the loading screen section. Many modern games for past decade, while still having loading screens, are still too big to practically fit everything in RAM, they load things while you play and there's different kind of data streaming methods and implementations from game to game. They all have a common goal, populate the 3D world ASAP without affecting playability right, it should never interrupt the execution of the core engine, so that there are no stutters. Reminder that a stutter in this case (seen as a FPS drop) is caused by the pause in execution of the main thread, let that be clear, it has nothing to do with GPU and graphics, FPS drops as a consequence because there's simply nothing to render for a period of time. -------------------------------------------------------------------------------------------------------- /////////////////////////////////////////////////////////////////////////////////////////////////////////// -------------------------------------------------------------------------------------------------------- The Test: The most obvious scene when I think the Disk I/O loading has the biggest impact is with the use of a targeting pod and other imaging sensors that scan or view terrain far infront of the players aircraft, such as a TGP or MAV imaging. Those distant areas may have to be loaded from disk because they weren't loaded before, since RAM is limited, other data has to be dumped from RAM to accomodate the new terrain data where your sensor is looking at that moment, so the cycle can continue unless one has a really big amount of RAM and VRAM. So for this test I used A-10C with TGP and MAV flying around the Caucasus map, as mentioned it's barebone, so no other units or activity of any kind. I only posted the results from my primary Win10 PC tests. Default CPU Affinity Case: Image Album: https://imgur.com/a/hzadyBf -------------------------------------------------------------------------------------------------------- /////////////////////////////////////////////////////////////////////////////////////////////////////////// -------------------------------------------------------------------------------------------------------- Workaround CPU Affinity Case: In this case I used Process Hacker to set the DCS Main Thread's CPU affinity to only 1 CPU of the 4 I have (HTT/SMT disabled), while setting all of the other threads away from core CPU0 accordingly, as well as some of the key processes unrelated to DCS such as Process Hacker it self, MSI Afterburner, DWM and some other system processes that are critical but may take 2-3% of 4xCPU, so the DCS Main Thread effectively "gets" an exclusive core to it self. The threads you see on the screenshot above are from the fully loaded mission start state, on the "FLY" screen. Image Album: https://imgur.com/a/o8qvQ79 As you can see the behavior with the A-10C TGP is much better, while the FPS is expectedly variating, there is no hard stutters or very low FPS drops of any kind, it feels smooth, if I wouldn't have any graphs displayed and playing normally I wouldn't notice the FPS differences. However, this can't be easily seen with just the screenshots, I avoided recording a video when doing these screenshots because the CPU requirements of real-time recording would interfere with the test results. It would require a much beefier CPU, or GPU that could handle the offloading of video encoding and the game at the same time. -------------------------------------------------------------------------------------------------------- /////////////////////////////////////////////////////////////////////////////////////////////////////////// -------------------------------------------------------------------------------------------------------- Side-Issue: The Loading Screen Unresponsiveness I distinctly remember this did not happen some years ago. When you click with mouse the standard Windows unresponsive error appears, but it has no consequence, loading as normal. DCS may not properly be signaling Windows it's infact all okay, just loading something really hard. This may just be a rather minor issue with the way app responds with windows, analysis shows that the main thread is 100% loaded during loading screens half the time, while disk I/O loaders also help out. Fixing this won't mean the main thread will be alleviated of much of the workload, we don't need it to. -------------------------------------------------------------------------------------------------------- /////////////////////////////////////////////////////////////////////////////////////////////////////////// -------------------------------------------------------------------------------------------------------- Testing the track yourself: -------------------------------------------------------------------------------------------------------- /////////////////////////////////////////////////////////////////////////////////////////////////////////// -------------------------------------------------------------------------------------------------------- Options and PC details: -------------------------------------------------------------------------------------------------------- /////////////////////////////////////////////////////////////////////////////////////////////////////////// -------------------------------------------------------------------------------------------------------- Update1: Feb 2021 Major Reword ProcessHacker Nightly Download StandbyCacheFlusher.zip TRACK_DCS-256OB_TEST_CAUC_A10C_BareBone-TGP-MAV-TerrainHorizon-DiskIO-Lag_27March2020.trk -------------------------------------------------------------------------------------------------- ///////////////////////////////////////////////////////////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------------------------------------------------------------------------------------------- WIP

Yeah this needs complete adjustment, it's about lighting and as mentioned lighting is a touchy thing that will take time so don't expect it to be solved so soon, if you don't like it you would need to use the release version. Hm, I'd be surprised if only that setting would fix it.

Emmm ... similar :)

Oh people, what's wrong with Eurofighter, that's freaking great! I remember the old shows on Discovery Channel, talking about planes, machines, and stuff, and it was "INTRODUCING DA EUROFIGHER"... I'm so mad I didn't record them on DVR, but I did went back and managed to do 1080p rebroadcast versions of some. I don't think I have anything on eurofighter tho, not for some detail information purposes, but for the coolness :) I thought that was it, and I'd be fine with it.

Set your mouse to use 100hz pollrate in your mouse driver software, if you have a modern mouse and drivers. DCS has some issues with 1000hz gaming mice, but it doesn't affect everyone, more of a minority. The old mouse probably had 500hz pollrate that's why it was better, because it only seems to work right on 100hz and anything higher makes it chug and act erracitally, quite a nasty bug or whatever it is. I had this for years and it took me forever to figure out.

I don't have a problem paying for DCS A-10C Warthog 2 upgrade! Infact I'm not sure if all those core upgrades can be all free, they will be practically, but I think it has to be pulled from somewhere. But I suppose 3rd party Modules do go into the DCS core partially ... kinda like game publishers.

It's the other way around, devs needs help from us posting good reports and details ;)

Yeah, it's just not the AI literally, it's the models I think, AI controlled or not, static as well.

Indeed, including a draw call counter. What's also the surest way is like a "huge" special mission which would test a bazillion of scenarios and would perhaps run overnight and some, but we can probably tone it down to some key scenarios, perhaps a quick version for cases like this with some key perf data relevant for users. Combinations combinations combinations. DCS has so many systems, and depending on the mish-mash you're happen to be into you'll get different results even if you're on the same exact specs, you'll get different results if you use MAV or TGP for example, MAV is more expensive on GPU, that small detail would technically invalidate a test for example. This would be beyond tracks, this has to be an actual component built for it specifically, running the scripted tests and more than just general tests but rather split by components to figure out their impact individually and be able to home down on culprits, automatically gathering perf data into report, calculating and giving you a % of difference versus another report that you took in another version (if that version supported this benchmarking at all). It could perhaps even be a separate utility outside DCS because for a more surer tests it should researt DCS and clear up standby memory before each new test so you can simulate the worst-case cold boot scenario for every test and that's should be the target, because standby memory is just a convenience IMO, but we've grown so used to it that we take it for granted, if it works nice on cold boot it should work even better after you've been playing for some time. I might post a draft idea in a separate thread in the future, perhaps I may just make a draft mission that tests some limited things as proof of concept. I got some nice clues up will post it today hopefully it helps ... there may be a common problem to this. I should have been on hiatus by now, but after successfully putting in another 8GB of RAM finally, so much overdue, to get me to 32GB I just couldn't miss to not test it and the the month of free trials wouldn't let me go, it's great bug hunting opportunity on modules I never planned buying. Things I do for DCS :)

Yes DCS seems to think I have unplugged TrackIR when I was unplugging a standard USB Storage stick- That's about it, I used TrackIR and have it setup because I was experimenting with OpenTrack and Wiimote, it was kinda a good try but not really usable in practice, way too little FOV, I'll just get a proper TrackIR sometime.

Except ... the CGI looks way too modern and clean-looking, they should have added filmgrain or at least made it less glossy and lower the color saturation of the water.

Russian Ministry of Defense must be a fan of DCS, what a great trailer isn't it :D

2.5.6 upgraded a lot of the engine components, many dlls don't exist anymore and some are new, the old protection is also removed completely that's why you will not see dcs_protect.dll, a10_protect.dll, CombinedArms_protect.dll, and fc3_protect.dll, which is great because these things caused constant spikes on CPU, but not on the main thread so normally wasn't noticable.

Yes, because it's so important that we look properly at the perf data, and to quickly and easily gauge this without using advanced perf tools one must look at the CPU Total Usage specific to that PC's CPU amount of cores and that nothing else is taking CPU on the computer at the time of reading, while preferrably having HT/SMT disabled for obvious reasons of complexity trying to gauge the mystery of HT/SMT because those extra logical cores don't count the same % in reality as they would when just dividing Then it's more of a mystery how the thread scheduler works if it prefers to separate threads onto physical cores rather than treating the logical ones as equal, end-users just don't have the insights into these thigns but I think as more and more this develops people will get more demanding to know the details, hopefully the industry does provide way to perf this stuff in general. So that, looking at Per-Core CPU usage is wrong because normally all would jump from core to core (unless specifically set/forced by developer or user option, that I don't know of right now) Now threads can have an IdealCPU and if they're really busy they may tag themselfs to a particular core and it may reflect that in the per-Core CPU usage views but I wouldn't rely on it.