Worrazen

So here we are, after quite a large gap between the last time I was doing diags with DCS, I kinda put that deep one on hold because I didn't want to jump to any conclusions, with a program a lot more detailed and sophisticated than the one in this post. I wanted to get in to the bottom of what's responsible for what, but I realized the task is quite a bit more complicated. With quite some new people around since then, who aren't up to speed with the DCS performance stuff, I decided to make this overview of the DCS threads behavior, with some general observations and not trying to go into definitive detail, it should do the trick for most people to get a sense of the status of "Multi-Core Support" (there's no such thing :p) Initially in this post, I got into a small A-10C mission, and because I've seen different behavior with different modules, maps, types of units on ground and/or air, radars, EWR, the types of actions you're performing (TGP usage, types of weapons), and so on, it is very important to always associate any such DCS performance stats with a specific scenario that was used when recording. This case obviously did not have any missle AA units, scanners, radars, EWR, there was no ECM usage, no countermeasures, and I didn't even have GBU's to drop due to mission's default loadout choice. The way you read/interpret this PerfMon graph is, .... well I'm not really sure as I used it more lightly, which is weird as It's me who should have figured out this before posting, but this is all niche stuff with scarse info on the web, the point is it's good enough to get you an idea how things may be under the hood. It probably safe to say that 1 thread isn't taking, at some point over 80% of the whole CPU which is a Quad-Core, that wouldn't make any sense, so that wouldn't be correct interpretation. One thread can only do 25% on a Quad-Core with HT disabled, so 100% of all cores divided by 4 is 25%. A lot of statistical data is lost when viewing total CPU usage of a process, that's why using Task Manager is not recommended, it's hardly reality at that point, most system administrators and other IT specialists within the industry know that Task Manager is garbage and it's solely made for the average user to get a rough idea of the system's health and status. So interpreting this graph in a sense that when you look at a color, a thread, the scale on the left being how much this thread was taking in regards to the CPU core it was on. So Blue Thread was taking 80% of CPU Time on CPU2. That is the correct idea and does apply in general how it works, but still take this specific graph with a grain of salt. An example of a finding: (There's so many threads that one got the same color, I forgot to change one of the reds to a different color) So we got mostly Blue, Two Reds and Cyan, and spikes from a Yellow. So everything more than 4 is going to start filling into the same 4 CPUs we have in this case, but keep in mind that we're not maxing out the other 2-3 cores, there's still space for many threads with light load to fit into the 3 threads. Now you can see where this case would get a potential slowdown, or a stutter, you can see in the middle roughly there's a spike of a Yellow graph, and that's a 5-th color, that would mean we got one thread here that has to fit in those 4 Cores and potentially be forced-in taking away headroom from the rest, we might be bottlenecking, well not necessairly ... ... Remember we still have headroom, that Yellow spike shouldn't affect the main thread, it's not big enoguh, it could fit in any of the cores that still have headroom, but what we can observe suspiciously is that there is a correlation with the main thread dropping down at the same time the Yellow thread is spiking, that's not what we would like to see if we want optimization, it could be a coincidence or a bug/issue/design in the DCS engine it self. Having to pause some type of workload on the main thread while a different workload on a different thread is taking place is extinguishing the point of multi-threading. Such cases, if true, would give us a false sense of optimization and multi-threading, if we were to just look at raw numbers, eye balling the data, looking at number of threads and their activities. So with all diagnostics and analysis it's very important to look at many different types of views and take things seriously, interpreting the diagnostic data correctly is very important and the last thing I would like to do here is to create some panic among the community by wrongly interpreting the data, or giving false sense of performance. What I can say for certain it's definitely better than what people think it is. Back to our little example here, ... if the main thread has to stop for another thread to work then what's the point of that workload being on another thread right! But we still have to take all the factors and conditions into account, this graph is a replay of a 30 minute A-10C flying around doing stuff that you can see in the video, but also AIs doing it's own thing, it can get very complicated of who's responsible for what spike/event on the graph, you can separate with specific scenarios designed for that, but in general gameplay it's all molded together. I've did many such things in the past and boy the graphs get interesting when you destroy 500 units and there's a huge load of smoke, those are specific case examples which are complicated and I didn't want to post those on purpose because it's hard to explain all the tiny circumstances, without doing a live take video where you would see, unfortunately the other programs are extremely resource intensive and wouldn't be able to run both DCS and them at the same time, recording diagnostic data is already a resource hog by it self, but Windows Performance Toolkit isn't even designed for real-time operation anyway. So that's why it's key to not jump to conclusions, and the deeper you dig it actually presents more questions and more places to dig further, then it's obvious that everything's extremely relative to the scenario. People that report stuttering versus other people that don't may just be using different modules with different maps playing a different style of gameplay and using different weapons and systems. So when looking at diagnostic data and graphs always keep a sharp lookout on the whole situation. Again, this scenario was not using any radars, any ships, and missle AA batteries, all the data is relative to this scenario in the video below. There may be other benefits of putting things on a different thread but still being kinda tied to the main operation from various development point of views that I do not know about, but maybe that's a dud, I don't know, but generally something happening on another thread should not be stopping other things and getting in-the-way, that said this is still looking back at DCS as most of the core improvements haven't come, it's a look back at the last decade, so if anyone's reading this years down the line, there's no reason to be concerned, it's looking far better as it is, we all thought it's only running on 1 thread, well nope, so things are just going to get better from here on out. There's no reason to concern overall, there's no cases where it's super bad, overall DCS is hard on the system yes, but I didn't see any hard bugs or indications of them, except the A10C_Protect.dll and FC3_Protect.dll seem to be kinda legacy things chugging along there taking a bit of CPU regularly, even tho if you're not flying A10C or any FC3 aircraft in a session, again those may just be names with other modules using it, while I'm speculating other newer modules seem to have their protection performance hit probably tied with DCS_protect.dll which isn't that big alone, let's just hope it's not stopping the main thread when it's taking CPU time. A basic overview of the threads with approximated descriptions: The basic case scenario video: So what are the observations we can probably make: There's one thread that seems to be taking more CPU time than any other one. Audio seems to be on it's own threads Storage Access (IO) seems to be on it's own threads Copy Protections seem to be on their own threads Some part of the graphics and driver stuff is separate Some controls input may be separate as well TacView plugin is on it's own thread too Also, please note that the thread Start Addresses may not be 100% accurate/valid of what we're assuming the workload is, because it can be convoluted in code as things may be called from one place but work being done elsewhere, spread across differently below the calling piece of code. So don't take it as it's written in stone, althought it does make sense with the rest of the data for the most part, we know from the devs that IO is split from the main thread, we know from the devs that Audio is split from the main thread, at least that's what I'm aware of. Just keep in mind that there could be other types of work on that thread apart from what it's Start Address may seem to tell us about, so an audio thread may not be exclusively doing just audio work, for example. 2020 And Beyond: (More opinion style!!!) We'll see a major change in these stats when Vulkan API comes, unless some big new feature comes that takes up all that gained performance, but I doubt it, I believe all the driver overhead and draw calls run on the main thread and that's a big thing Vulkan based GFX engine will deal with. The next big thing to alleviate off the Main ("simulation") thread is the AI if we are to believe the basic thread info, it has to be spun off the main thread ASAP, I don't see how AI logic per-unit would need to be on the main thread where physics calculations happen. There's proably loads of serial workloads that don't have anything to do with each other math-wise. While you fire a missile at an AI1 airplane and that missile calculations have to go on and it's taking a lot of CPU time on Thread1, what's keeping some distant AI3 from running it's separate AI logic on Thread2 for landing or whatever, right right!?!? So there's a lot of potential to split away these serial task into many threads. Each unit on the battlefield or rather squad could probably run not only in it's own thread, but it's own set of threads (by type) if you ask me. Mission Editor logic and triggers, waypoints, etc, maybe don't have to run on the main thread either (I could be wrong a bit if there's a thing to do with events/detection, but conditions nah) So if the ME logic, a condition, checks for IF THIS UNIT IN ZONE A, it doesn't have to be on the main thread, sync with physics shouldn't be needed because it may fire what at most 100 ms later than it would otherwise, that's probably nothing in practice, and DCS matches with complex ME logic will probably have 1000x of factors so the chances of this discrepancy, but then again I'm talking worst case scenario. What I'm talking about is like, you entered zone A by a few meters, but because ME logic was late it did't register, but then you got hit by missile and then you happen to fail the mission. Chances of this being a problem? Then again, because the Main thread is bloated, moving it off might even make things better for this part. The thing I'm afraid is that this sync could be important for Multiplayer and you don't want each client have different away from what the main network is sending out, ... but what the heck am I saying, ME Logics should and probably is running exclusively on the dedicated server host, not the clients. So we'll see how deep the devs are willing to go to split what is splittable, it's a big deal for engine programmers though and not something that will happen overnight, they should really hire some extra IMO because the longterm benefits are worth it especially when there's features coming that will need that extra performance headroom, but also new CPUs are going crazy on amount of cores. Once this is all done, the Main thread may look less and less like the main one in terms of CPU Time, that's right, but you're still suppose to call it the Main one IMO, because in technical detail it is still the one holding the process together, the engine, being the parent and responsible and stuff ;)

That's a stretch, it's quite a bit more complicated than this. We gone over this a lot in the past threads, and DCS is as most applications are, already multi threaded, the question is how good and how good it can be, how good it can be is unfortunately lower than most games because it's a simulator with a lot of serial type of workload that cannot be parallelized, so we need to forget about the level of multi-threading other modern physics-less games can be. That said improvements can still be done in this regard to get everything away and the main simulation thread, the serial workloads that have to be part of the same thread, to have the best an most optimal conditions and have the space all for it self, while other stuff is put on their own threads.

You need at least a 250GB SSD for DCS more or less. Updates that are coming are going to be ever bigger (tho it does overwrite a lot), even if you don't get more modules.

Actually ... there seems to be something else going on across the board with the knobs. Seems like there's a rule that switches use right click to switch right, and left click to switch left, irrespective of function making sense in terms of increase/decrease or off/on. I think I found a thread about this sort of stuff, so this is a known thing out there apparently: https://forums.eagle.ru/showthread.php?t=178714

Great, but also, let's not jump to conclusions, lighting can be a tricky thing, and the way screen and buttons feel when they are lit is quite a big deal to me, and I don't expect fixes overnight but I also hope there is understanding that this may need tuning for some time. Recreating that very glow-like appearance to be accurate is the key and when it looks right it's so so great, but if it looks off it makes it looks cheap. But I don't think any light engine by it self is going to make this look right, this is same as developing textures, it has to be done by someone to have the right looks, probably a bunch of layers of effects to get it right.

Oh oh so there are people talking about this similar thing I was just figuring out, I wondered about the knows for a long time but I guess it wasn't that big for me to come out looking. Seems like there's quite a bunch of these inconsistencies going on, beyond of what my main issue seems to be. So I'm not sure yet what inconsistency it's meant, but to me why I came looking for this is because there seems to be this rule that all knobs would rotate to right with right mouse button and to the left with the left button, so I was thinking perhaps it was intended that way and may not be considered a bug. I just happen to not be a fan of this behavior so I propose there could be an option for this to behave differently, or at least a workaround if I can mod myself, just like there's a mod in this thread. I'm going try this mod, and get to know how clickabledata.lua works.

--- Note *** Significant time passed since last post ---- Things may have changed since the above post, but definitely the rotation of the knobs is still following the global physical mouse-left-right rule, which means a right click moves the knob right, a left click moves it left, irrespective of making sense in terms of "off/on" or "increase/decrease". But if it wasn't changed for so long, makes me think if this was intended, and since there is some logic behind it, it may actually be a valid choice, but I think this needs to be an actual choice as an official option between the two behaviors. Some people may actually prefer to have this standard way of knob rotation behavior.

I did more tests with different scenarios and with one I just went on without resetting the master caution and continued normal procedure, turns out it's the APU GEN and that's because the APU GEN light is not flashing when it is suppose to. It was already reported twice. https://forums.eagle.ru/showthread.php?t=260126

Update 2: The AN/ARC-164 UHF radio in DCS, has a 3 stage button same as on the VHF, it seems, but cannot be set to LEFT, it looks like it's either CENTER or RIGHT position. Please check this out too. The Squelch only has 2 options, so it would probably be a 2 stage switch IMO.

http://ch-47helicopters.tpub.com/TM-1-1520-240-10/css/TM-1-1520-240-10_137.htm Update, well, yeah, I ofcourse had an eye-peeled because of the new cockpit textures update to hunt for bugs, and that's what I was going to get to and sure enough .. Seems like the ON and OFF labels are switched versus the Manual, but if that's correct like it should have been in the first place, the function was indeed in reverse the wrong way all the time, it just worked right because the textures were synced up, but now it's not in sync. And then I went back futher, why was I confused with the VHF's SQDIS, because it seems the new textures place things quite a bit more compact, I think the font is smaller and the whole thing feels smaller a bit, there is no gap between SQ and DIS so it appears like it's a one word.

The OP did make a point but didn't mention it, getting power up faster to turn on the navigation alignment stuff in airplanes such as A-10C is a thing, so you can takeoff faster, it is therefore a military/gameplay advantage and it could mean something if things go by a hair amount. The manual it self mentions enabling CDU and EGI ASAP, but A-10C APU is so cool as we know, it generates limited electrical power to the avionics, so you can power key systems off that. Still there's always and advantage with backup, secondary and failsafe systems, even if the primary systems seems so reliable that it doesn't need anything else, in battle when a key moment is at the hand it can be a big big deal as the designers probably foresaw, they put those backup tricks there for a good reason :thumbup:

Let's hope it's just the textures, you should posted this in the Bugs section tho.

Hello So as I'm also dealing with some little radio amateurism as a hobby on the side, I noticed some confusion with SQUELCH TONE in the A-10C manual and the functions inside the cockpit's radios. To my knowledge, Squelch is a system that mutes the audio output in order to only make "valid" signals hearable such as voice, so the background static noise on the frequency is unheard. Right? So by enabling this, then you stop hearing the background noise. So the DCS: A-10C Manual, for AN/ARC-168 says "Squelch Switch: Provides Squelch Tone" This statement does not make sense because squelch doesn't make a tone right, it mutes the background noise? However now I see the AN/ARC-168 has 3 settings, and after thinking it's wrong, I correct, and I think it's working fine, the center default setting seems to be enabled, and the left is disabled (finally figured the odd labeling SQDIS ... it's SQ for Squelch and DIS for disabled), so I guess it's working right, I can hear the background noise when setting to DIS, and only voice when center, but the TONE setting is not sticky and I didn't figure it out what it does, I didn't hear any extra tone. Perhaps the devs were confused by the AN/ARC-168's TONE setting that it was written like that, but that's not the main function of squelch so this should be fixed in the manual. Whereas the AN/ARC-164 has the more simple ON/OFF settings for the Squelch and it's quite a bit clearer on the panel as SQUELCH is spelled out fully. But the manual says exactly the same thing as with the VHF radios. HOWEVER, it works in reverse in DCS, I can hear the background static when AN/ARC-164 UHF Squelch is set to ON, that's not right is it!?!? Thanks

This may not be directly related, more with damage modelling, but fuel tankers deserve more damage modelling than normal transport jets, it's heavy fuel, possibly flammable, but in terms of air-refueling, if the line gets loose, damaged in a way, or that there would be fuel spillage, there should be some damage modelling from spilled fuel in terms of possbility of that dispersed fuel igniting by the temperature of the receiving jet's engine, ofcourse more change if afterburner on, but the mixture has to get close enough, so the fuel-air stuff could be modelled for that purpose. If it ignites it could ignite into a fireball depending on how that fuel is dispersed by the malfunctioned boom/cable, so it may travel toward upwards along the lenght of the receiving airplane and that could perhaps cause damage or something, damaging antennas, sensors or something, schorching the canopy making it smudged and harder to see out, the flames wouldn't then travel upward the cable/boom ofcourse, but I guess if you immediately move away after ignition then you may just be lucky to get away with it as the materials will yet to absorb the heat, and in the end the tanker could be continuing with it's flight with a burning flame behind ... except if the operator then shuts off the supply shortly after things Ah it's a bit of a thing, then it would need to simulate the delay of operator shutting down the supply (valve) and remaining fuel in the boom/cable ... so unless some enemy aircraft kills the operator by shooting right there at the back I guess the burning effect won't last long, but in theory that should be possible, if no boom operator to close the valve, it would leak indefinitely and if burning, would also burn indefinitely ... IF .... ofcourse kerosense is able to ignite in air like this (I think yes if high enough heat) and then it would be determined by environment how long that lasts, super high wind or speed or manouvers by the tanker, rain, snow, fog, clouds, could extinguish the flame, by varying degrees.

Hello One thing I finally reminded myself of mentioning is that the Master CMS Mode Select switch seems to me that works in reverse, it's not the left click, but right click enables the system gradually from off to full auto, I seem to always get confused with this button. It should be the left click that sets to STBY when it's set to OFF, and so on. Thanks a lot, little detail, but really would help!

Update: I did the same thing (had to restart as server kicked me out after AFK) but I started the right engine first, same thing, however, after doing the same for the other engine, once the right generator and engine was running, it didn't do any Master Caution. I guess this may be a thing because we usually we just flip both switches up before starting any engine? I don't always start the same as I sometimes forget the procedure a bit and refresh memory. But when Master Caution is flipping, the R or L GEN is not flashing, it's just lit as per normal. Perhaps if the system does expect both switches to be flipped up when any engine is started and this is intended, then the warning for the other GEN green light should flash along with the master caution. So the bug may be that it's not flashing?

Hello So I went on an MP server, PvE with a lot of slots for airplanes, I chose A-10C and proceeded cold start, so I fired up APU, enabled CDU and other stuff, played with DSMS, loadouts, I fired up first the left engine with only the APU POWER GENerator enabled, I think the master caution normally starts when an engine finishes spooling up and the corresponding generator is not turned on, after I enabled L-GEN, the warning light disappeared, but the master caution kept going, I cycled the L-GEN POWER switch but the "issue" persisted. I'm not sure it may be some oddball case, but it does look unusual to me.

I heard Cap said he's losing viewers over B-52 being an old model with old damage effects ::music_whistling: But ... we're getting there

Right, that's it, I get it now.

But it's not just "clouds", it's a whole weather system, with other parts later on, so it's a bigger technical deal. "new clouds" is a heavy understatement, not that simple at all, so I would relax and give it more thought in a few months.

If there's no news, means it's just either going on with no specialties, or it's not close to release, not much to fiddle about.

PSUs can be sneaky, it's very easy to get confused with rails and amps, Wattage doesn't really mean that much as it's being portrayed. I was absolutely capping the +12V line in terms of amps and didn't even knew it as the previous PSU was just that good and kept chugging along, that's why I was getting weird behavior in other cases (like weird drops of screen going black but PC still running, freezes, BSODs), even tho all games worked and I played them fine. So now I got a proper single-rail PSU, actually this model has a physical switch to make it single or multi-rail, but I will never by multi-rail only PSUs again if I can, it takes planning and it takes a well calculated approach, which I don't want to be bothered with as I change components and modify my system on almost a tri monhly basis as I maintain it, upgrade HDDs, change stuff around, more HDDs, changing this, that, etc. Multi-Rail would be fine for like OEM when the PC is under warranty and nothing will be changed from the specs in the beginning for that period.

I don't fully understand it yet because I haven't done mixed loads yet, apart from the stock training mission. I was reporting on what I was doing earlier with non-mixed loads. EDIT: Allright so the weapon selector only means which pylon fires first, if it's the correct type, it'll keep firing from other pylons if the selected one is empty. A bit unexpected to work like that, but whatever. Yeah I tested the priority now, the lock won't work unless I select IR, and I purposelly selected a wrong pylon, it still fired the IR missile from the other pylon, again I wouldn't it expect to work like that, interesting.

So I made a custom test mission now. I used only R-3S which are IR. Selected Pylon 3, it did fire from pylon 3 on the first time but proceeded to fire from all other pylons if I kept firing. I didn't lock on with the radar. It takes sometimes precise alignment but the "LNCH" light shows up whenever the lockon sound plays. No green lights. Then I used only R-3R. I locked on with the radar and there was a lockon sound shortly after. However no LNCH light, and no LNCH or HR lights in the radar, no green lights either. After getting closer then the LNCH light would fire up, and LNCH and HR would light up in the radar, but no green lights, while the sound keeps playing. On more occasions seems like the LNCH light lights up much later when getting closer to the target, while LNCH and HR on the radar were lit up way before. Okay so now I know that sound is from the missiles, not from the radar, and it's the same sound. If that's how it's suppose to be then fine, I don't know, but the only thing left is the fact that it keeps firing from all pylons, so the selector doesn't do anything other than selecting between single or pair, for both of these missile types. That doesn't seem right hm? I'll test with other missiles now.

I went again and yeah it says to place it on number 3 and the first pylon on left is number 1, which is I guess counting from center, and the first from the right is number 2 ... So it's like 3 1 2 4 (if we ignore the others), but I think that doesn't match with the loadouts page, oh well. I just didn't seem to get IR stuff working, so I made a new fresh mission with only IR missiles and will try if I can get a lock there, i mean, those green lights and sound to fire up, since I never got that whatever pylon I selected back in the training mission.