Worrazen

I did saw that video somewhere, that's good if you get improvement, but I never had the affinty bug, not sure what would set it to one CPU only, it always used all CPUs for me, and I don't always have HT enabled either, and I still have the older traditional intel CPU, not the newer CCD/CCX designs. Looking at the thread breakdown in single-core test below, it's pretty obvious why you get a perf boost when switching to multi-core. (posting it any minute now) Except, the DX11 "rendering" overhead is PRETTY BIG, enough to send you down below 20 FPS. It's not just proper render command multithreading, it's much less driver overhead, and draw calls cost less by orders of magnitude.

Okay I got some results, after digging into WPR/WPA for like 6 hours this morning, going through the MS docs/tutorials, I was rusty for a whole week but got back into it to actually display things correctly, but I need to make screenshots and label it all it may take another third of the day, but before I begin that, one thing that's very important with any kind of deep brainstorming on a PC is to take a break outside in the beautiful weather :) -- How much CPU cores it's using and what the thread behavior is can be done in one screenshot, but going forward to show things how they work in a really good way beyond just totals and summaries I would actually need to make a video of the whole mission replay being played side-by-side with the charts in the WPA with an added timeline cursor on the chart. It'll need some video editing to add a timeline cursor and figuring out the sync so it actually moves correctly proportional to the DCS mission replay time and the events on the chart. Secondly it's a lot of horizontalness with all of this side-by-side stuff ... might have to figure some way, turn the monitor to vertical and have it above-below window positioning but I never tried that yet.

Well I didn't see a huge impact with this test. There's one weird effect in this program apparently that sometimes it doesn't run full speed, in the first test you can see the green bar is missing a bit in the Multi-Threaded section and thus being beaten by the Single-Threaded one, even tho in this case both are forced onto their own respective cores. When I set the affinity of the multi-threaded one to more than one CPU then this behavior switches around, it may be some kind of an external factor so this should be treated as error margin and treated as if there's no difference, at least in this specific video case. Process Lasso will be quite handy ... I thought I'd contriube a bit and took a monthly subscription of the PRO version to assist with testing even more :)

We've gone over that yes, if you were able to pull out the point of my above post, that the only "problem" with Thread Bouncing is just for when a person tries to dissect what is what and where and how much, there is no easy straightforward way to do it, as far as I know right now. How is "parallel processing" going to help you with a serial workload? Just having a "parallel processor" and putting 1 thread on it to jump around isn't going to speed anything up as we already established. They're just overblowing the parallelization thing, it could be PR hype, to make 10 million gamers think their Windows is "parallelizing their game threads". While in simple logic the real reason may not be performance IMO, it may be small, it may be due to some cache-stuff being prepared or some look-ahead stuff the CPU could be doing, the heat-power stuff isn't that clear either but it makes sense, it could be only with heat distribution in the heatspreader and therefore avoding one part of the CPU being more hot, but that's like so far away from anything so important, like all this thread bouncing, scheduling, just for some heat spreading ... if it doesn't decrease perf, which yes it doesn't, then why not, but it's kinda weird why would they just not be honest and they keep hyping up this parallel obsession. Let's say you have a Quad-Core CPU and if you set DCS most hungry thread on CPU0 it would simply stay there, consdering you're not doing much with the PC while you're playing DCS then CPU0 wouldn't be used up much by anything else and if it were then the scheduler would have cleared the way and moved other threads out for that DCS main thread to take up as much as it wants on CPU0, you would still have the scheduler doing it's thing for all the rest of the DCS threads and the programs/OS. This type of setup should be tested gainst the fully thread-jumpy one and let's see what really are the perf, power, heat, stability differences, one popular tech reviewer could try such a thing and get this confusion sorted out once and for all, hopefully, if there was just a way to do per-thread affinity without needing the developer builds or needing in-game support necessairly. Otherwise I could have done this test already and we'd get to the bottom right here. Now at last, one of the performance benefits of thread affinity is that you would be able to use it with a particular overclocked core, some CPUs have a varying degree of core quality inside, some cores are more stable than others, some cores perform better than others, some are more overclocable than others, a pro-gamer could figure out which core is the best on a particular CPU, overclock that core, and because it's only one core it wouldn't heat up the PC as much, it wouldn't draw that much power either, probably would be more stable as you're not touching the less stable cores, and you get ALL the benefits in DCS and similar software which relies on single-core performance. This is actually a more feasible practical scenario, but to prove it first the DCS developers would need to open up support for this in the settings. ---- Your first post was exactly what I was figuring out, and reconfirmed recently with a refresh that this thread triggered in my mind, it's all a power-heat thing, it's not a maximization of the performance. Please read my posts carefully as I put a lot of time into them, I was in no way shape or form saying that anyone has to be configuring CPU Affinity, that's only done as a tweak in case things don't work right by default, and in cases of troubleshooting and analysis. Besides other people on this forum have experimented with CPU Affinity a long time ago already and there's whole threads about just that.

Inside a computer game it's asking for problems. Let the technology progress a bit.

I think I can agree it's going to take away from motivating people to skill up ... this can actually have quite a big effect on the whole community, even with all the upsides, this downside is very heavy IMO. A long campaign might have some kind of checkpoints tho ...

I'll be putting some of the replies about multi-threading into a better suited wishlist thread here that's going rounds at this time: https://forums.eagle.ru/showthread.php?p=3953342#post3953342

More appropriate thread to reply to: From the DCS Update Patch Notes Actually I didn't say necessairly said that the type of scheduling is less optimal ... althought I agree I was jumping around with many theories, speculations and changes of opinion during that forums thread. Thread bouncing may just be a normal thing that was always present, maybe it's bouncing way more rapidly on newer modern systems than on older, I'm not sure, there isn't that much of a difference on most CPUs but it does indeed depend on the architecture, it does apparently become a problem if it doesn't schedule properly on newer much different architectures such as for example AMD's CCX and one of them may just be thread bouncing arbitrairly to a completely different CCX for no reason, in which the cache would need to be read from one CCX it originated from to the new CCX and the rest of the CPU Core level caches and in that case the thread would need to wait for the caches to finish being written to the new CCX before proceeding execution on the new CCX which would produce a stutter. That's how I remember it I think. One thing I worded wrongly or too harsh at first, even tho I wrote many paragraphs to explain it eventually but throughout all that the main point could have been forgotten, is that Task Manager does indeed show you correctly about the Core utilization, so it's not totally wrong as some people reading those posts may think, it is strictly just utilization, there no other context to it, zero thread context, this is not explained or indicated by TaskManager nor MS (well maybe in dev docs) and most people including me would interpret it wrongly, I believe this is a mass confusion because almost everyone in various reviews, tutorials, troubleshooting videos is looking at those TaskManager graphs in one way or another and may be doing it all wrong, same goes for the Memory, everyone looks at the Memory number there to the left, that's all wrong as well, Commit Chagre is the number to look because that's the number where things start crashing, that's the number that triggers Resource Exhaustion dialog, to put it simply. One of the biggest problems with this thread bouncing phenomena, is more in human analysis area, unless there's a better, easier, faster way I must have missed it, but it's awfully tricky to figure out with the tools I experimented with, including WPA, fidding with the correct filtering settings in WPA is a pain in the butt for me as an relatively inexperienced user there so far, even if I got it right I don't know I got it right so I have to dobule check and all ... Key points: 1. Thread bouncing is a global phenomenon, not a DCS specific one 2. Threads can be programmatically set to be favourited to a particular CPU core if devs so desire. 3. We as users can only set the CPU Affinity for a whole process, not a specific thread within a process (???), such an ability would have made things clear in any CPU core utilization utility and shown perfectly what is going on (ofcourse the more cores you have the more detailed that representation would be) and it would save me a ton of posting and explaining. Back to your quote: But that's not exactly accurate either, two-threaded, we only say that for convenience in practice, the threads that do the amount of work enough to mention, the wording really needs to be perfect as this is complex enough and any slight of confusion or misunderstanding can mean a big difference. It's not two-threaded in regards to the simulation, if you're talking about simulation as in just the physics part then that isn't multi-threaded right now and will probably never be because of the nature of the task as we know, each calculation relies on the result of the previous one. It's very very important that we define what do we mean by the term of "simulation", simulating physics, simulating AI, simulating sound, simulating weather, simulating traffic ... and I know you probably meant it correctly, just wording that is also the other part so others who don't know yet don't get confused. Here's some of the possible parallelization opportunities, generally speaking, the most obvious is the first case, then the second case for parellel tasks, but these things aren't immediately known, parallelization possibility in some things is hard to immediately figure out and gauge, these things weren't done on purpose to make it "better for single-core", they just happened, that's just the way things were programmed before multi-core was a thing, it didn't matter if a task is serial or it can be parallelized, many of these things aren't immediately known what they are as it's all sandwiched together, that's why it requires a lot of resources because it is necessary to figure it out how it works then figuring how it could work and looking for potential gains of separating things apart or de-sandwiching, and it sometimes such a big deal that it's basically rewriting whole batches of code rather than tacking some bits one by one, AFAIK. But the wording is again ... even a parallel task is a parallel just from a higher point of viewe, each of the subtasks of the parallel task is a serial task, so this can get confusing. Maybe it would be possible to split physics calculations between aircraft, so does the AI-physics run on a different thread? We could thread All-AI stuff as one big task and then treat it as Serial, but what if it CAN be parallelized in a bit, what if there's more separate serial tasks inside of AI stuff, AI-airplane-physics are probably not related to the AI-SAMSite-radar-logic or the AI-Command logic which commands the units around, is it? IMO Only if it has to do with sync (so everything is at the right place as it should be in every single frame) then it would have to be kept on the same thread. However Multiplayer is all each-PC simming it's own aircraft and then the server mashes it all together, if it's acceptable there then maybe it could be so on a local machine singleplayer evne tho I disagree with this as I think it introcudes, Multiplayer is probably quite a bit off and shouldn't be used for testing or as a basis.

Yes I was about to say, Yugoslavia had those... DCS Balkan Map !!!! I'd probably even be able to play over my house sooner or later :D There's Mostar Hangars too: https://www.forbes.com/sites/geoffreymorrison/2016/12/30/inside-an-abandoned-underground-yugoslavian-air-base/#115dac954f47

This one's more for the future unless it's not that hard to do, not sure, so I used the term units, but in practice it mostly benefits aircraft, where it's most useful, and probably not that important right now, but it can add to the ME experience quite a bit in certain situations. This would probably be very useful for making cinematic type videos where you want accurate replayability for developing a specific scene. And ofcourse campaign and missions, where applicable, it feels as if it's a step backward, but the AI's own pathing isn't exactly ace-perfect especially at low altitude and obstacles, unless if it gets heavily improved, still this isn't meant as a replacement at all, this is not for dogfights or any active combat area situation, this is for scripting the path of some background units, support units, AWACS, Tankers, Cargo, Paradrop, Carpet Bombing, the units that wouldn't normally go into a direct fight and wouldn't want to deviate, for example some critical supplies have to be delivered and you need to defend the C-180 flying low over a valley, you don't really want to deviate out of a valley as there's more units on each side, you're a cargo plane so you can't respond, you and if you're shot down the mission ends anyway so this feature is perfect for that. SCENARIO: An F/A-18 trying to wiggle between mountains, rivers, trees, passing close to mountain tops, while 2 F-16s are in hot pursuit. You could, if you want to, spend time and effort scripting that F/A-18C really good, then letting the F-16 on their own AI's pathing (depending on how good that is) and that might end up with some awesome results, if not better, probably a lot faster and less tedius than the clicks required to do the same with waypoint system. Remember, waypoints are just DOTs, the lines connecting them are just for visuals, they're not a path that the airplane necessairly follows, as much as it looks at first, which I fell for in the beginning, they are just defining the absolute shortest distance in between. A draft on would it work: (just an idea how I see it now, not how it must, ofcourse, could be better ways beyond this for sure) The ME would require some kind of a TacView-type 3D path creating capability for the user to accurately draw a path/track in full 3D. And/Or .. you guessed it ... ability to import a valid pre-recorded track replay that you did your self with any kind of aircraft and use it for the AI unit-s in your mission you're developing. Unfortunately, it's not that easy at first, for this to actually work right and be reliable, the valid 3D path/track has to be within unit-specific simulation parameters, it can't specify too fast or too slow speed for that aircraft, AOA, so it can't be out of bounds, and this may be depending on the factors I'm afraid a quite bit difficult, to do that and write it accurately, this is the hardest part of the feature most likely. The user can draw or generate a track no problem, but the target aircraft may not be able to fulfill it. Let's ignore the fact that AI-only aircraft aren't fully simulated as the paid modules right now, but they will be improved sooner or later, so that fact should be put aside and this 3D track validation system would target what an real fully simmed for example A-10C could do, and then you just happen to use an AI-A-10C in practice however it is simulated, because usually the less simulated it is the more capable/cheaty it probably can get (AOA, etc). So you can't just generate a track with your F/A-18 doing everything specific what an F/A-18 can do and "paste" it onto an A-10C to ride on, it won't be able to follow and will deviate considerably. So ... I mentioned how it may be the hardest part, there's many ways that can be done, like using the track can checking all corners and comparing the angle/distance to detect too tight corners, and that would have to be compared against a chart, ofcourse the devs would have to spend a ton of effort making such a chart as well ... but here's a very clever idea to save a ton of testing and manual scripting of the validation procedure... Once you've imported your generated track, or drawn up it your self manually in ME (or if a 3DTrackDrawer would be made separate?) ... You could just click "Verify 3D Tracks" and the engine would execute a special renderless preview of the actual gameplay sped-up in the background and wouldn't need to do any corner-calulation, in basics all it would need to do is to monitor the track-to-unit DELTA distance, the distance between the track and the unit, and that's super easy computationally, and you would then see the report in the end in a dialog with bunch of numbers. Everything we need to know are EASY calculations that can be obtained from time (completely free) and delta distance, average track deviation distance, max deviation distance and it's location(LAT-LONG and/or point on track lenght as distance from start), perhaps a list of top 5-10 biggest deviation distances and their positions, a bunch of other parameters I can't think of right now, and some kind of a final score/result number, and lastly the verdict statemement, in color, PASSED or FAILED. Additionally, the sensetivity/strictness of the test could also be adjusted a bit, perhaps allowing deviation off by a 1-2 meters/feet, absolute minimal wouldn't be 0 ofcourse, but some 0.1 or something even more for the engine inaccuracies and other factors (wind, etc) which is normal but in practice that's nothing. This test would also run on special circumstances, such as disable all other units, weapons, godmode, unlimited fuel, to test the track it self from start to finish completely (absolute). Even better, this testing ability could also DO enable low fuel and weapons, but for a DIFFERENT test, to test WHERE your riding path aircraft first got hit, or ran out of fuel, etc, it could do a bunch of such tests by default all in one or more runs, or you could choose just one you're looking if you're in hurry. The 3D path/track also should need to be speed-sensetive so the AI aircraft would replay at the same speed it was in the original replayed track, but that would be optional, you could be able to override the speed-layer with your own (repaint the path with speed-applying-brush) or the third option of just specifying constant speed, or average speed with min/max and a randomness slider. Then the AI support for such path-riding would be expanded with other capabilities, specifying the conditions where (numbered circle do-actions checkpoint) the AI could detach from the 3D path/track, do some actions like patrol for a certain amount of time, or detach and kill some enemies on the ground (normal AI's own pathing) then return to the 3D track by reattaching to it in the same place or another (actions checkpoing on the track) And a FORCE option to keep it attached even if it's attacked/damaged/low fuel/RTB/no engine which would just make it stay as close to the track as possible, ofocurse it would eventually deviate due to physics, but physics alone, the AI logic would still force controls to follow the track no matter what, to the death! This could initially just be done for limited amount of aircraft/units, for videos surely the top paid ones are the pick with shiny new visuals over the older AI-only model/livery aircraft/units. That's the idea that I had in mind for some years and another Wishlist post reminded me again about :) Now that I finished it I have a slight sense I might have posted this already years ago, but I remember having lot's of ideas stashed in unfinished posts, but whatever, at least it's written in a clearer/coherent/better way probably.

It used a lot of threads, the main point is how much of the work that matters is split up, it does seem more favorable than the hard-2-core-only conclusion that I got last time. I'm explaining about that as we speak in the other thread how I think I made a fatal flaw by using a barebone test to do the thread analysis. https://forums.eagle.ru/showthread.php?t=242646&page=5 It still led me to other discoveries like the thread bouncing thing.

That's a bit of a jump to conclusion isn't it? But the initial views and realization of the mistake does offer a better outlook right now. EDIT: I've seen your posts in other threads now JimmyWA, I believe this thread is about DCS multi-threaded optimizations, even tho the title is confusing, not about the CPU Affinity bug. DCS isn't exactly handled by a small studio, and Vulkan API happened to already be chosen over DX12. Me and others were cheering up for Vulkan API early on as well, but I'm sure they compared both options in practice with all the other reasons and decided on their own what the optimal way is.

That's what I had in mind for like ... 2 years now. This reminded me of another idea around TacView I wanted to mention for a long time, I'll need to open another thread for that.

We only say that for the sake of communicational convenience, you're absolutely correct. There's a ton of more detail in that past forum thread. The other threads just weren't contributing as much so we didn't talk about them. They are referring to my tests from I think more than a year ago now, if I remember correctly that test may have had one potentially fatal flaw in that it wasn't stressing out DCS but instead it was very barebone, however I did a lot of stuff at the time so I don't remember if that's true or not for the WPA tests, I did a video where it was barebone, no action, no flight, no airplanes, no terrain movement, raw rendering and audio, I fiddled with affinity and very clearly saw how enabling the second core had an big effect, while enabling the third core not so much, only 2-3 FPS. At least it proved that audio does take a good chunk and it's working right, so technically it is multi-threaded already in that sense if you use the english meaning of multi ... if it matters at all for me naturally that wouldn't be multi, because the concept of duality is strict with no exceptions in my language. I did a brief test now but I'm still preparing, majority part of the time it takes is learning how to use WPA and creating a proper custom mission inside DCS, then it'll take some more time to do the screenshots all over again with in depth explanation so a totally non-tech person can understand it, and I saw 2 more threads doing ~15% if I'm not mistaken each but this is all grain of salt as I was just browsing through the graphs, ofcourse you can as well do it yourselfs if I'm not fast enough, it's a moment when I'm also busy with other stuff, otherwise I would have done it already last week.

I'm taking a second look at that and this time more proper, possibly may change a bit, more stuff might have been offloaded off the main core.

Maybe yeah, I'm on cable 200/6 with 2 phone lines and +250 DTV channels and 30 HD ones, no caps, for 50 Euro. Just got upgraded from 150/4 like 2 months ago, however it was the first batch, the second batch will upgrade uploads from 6 to at least 10 or 12 Gbps in just a few months at the end of summer. :pilotfly: This ISP is using hybrid Fiber+Coax as they say so it's not FTTH, they had an upgrade on their end and it's all runing Docsis 3.0, but it's going to Docsis 3.1 in the near future.

... I never knew .... why does the dev team have to work, over night, and more, and then over weekend, for what is an OB release, are people THAT impatient? Anyway ... you reminded me, I'm actually not new to them at all.

Yes I think they should take their time, for that type of the product. Probably not a good idea to do any early-WIP sneak peaks because it's all about the first impression there and it needs to be good on day 1. I'd go as far to even include the update of the whole old non-flyable AI aircraft models/liveries before MAC, or block until they're updated. I just mentioned this in the other thread, the gamers at large are very sensetive to such surprises, me and probably we can handle the visual gap between the newest modules and the oldest AI aircraft which is getting bigger and bigger as we speak. It could be like stepping on a pin while walking upstairs at night for the newcomers there and they could be revolting about it or really taking the focus away from the main thing.

He probably meant models too when he said skins. I made big posts about this back many months already, for the general public, for MAC, if they see the 15 year old models when they'll be shooting that'll scare some people away so the AI-only unit external visuals are probably even more important going forward.

Shouldn't take more than a month, or two give or take. You can convert Stable into Beta with some config edits but I still haven't looked into that as never tried it myself yet. Not all the fixes are in yet in the beta anyway and as always it can be buggy especially with a new branch like this. Unless you purposelly want to beta test for feedback.

The first step is to not quit the game, there can be some offline prep, but most of the getting-used-to is not necessairly playing the tutorials but getting used to how the game works. If you force it into tutorials you'll still be skipping many other things and you'll have to learn that later, if you prefer that way than fine, but I don't, I prefer more natural and slower approach. The second step is to not play missions/tutorials at least a few weeks, take a whole month just learning the controls and random flying, it's about getting used to the simulator it self, that's going to help a lot when you get into training missions later, that kind of stuff can't be learned quick, at least for long term memory. Training missions will not be enjoyable if you're rushing into them, IMO. Since you already completed them, and you were overwhelmed in the first campaign mission, I'm assuming you basically jumped straight in, there's no more tutorials, well there could be, but for the getting-used-to, there is none you have to do it manually. Not exactly how I would like to referr to the DCS Community ... it's not like ED is The Borg ... or similar.

Any pics for those who don't have OB? You mean impact or rather streaks when they're fired form the gun?

I never tried it, I played it safe, but apparently as others are claiming that storage devices aren't part of the ... HWID? ... apparently so changing them won't change anything for the copy protection.

I guess a lot more is possible than I knew, I haven't went deeply into DCS modding yet even tho I was looking forward to all the time ... DCS is big and getting bigger, can't enjoy everthing that fast, I guess that's good which means it'll be lots of experiences for many many years to come. I've asked for this more than a year back in wishlist I think but I'm not sure if it's a new addition because of that or it was always in and I just never noticed it. I didn't notice the change in patch notes either, I read all the notes. But THANKS a lot for reminding us about it !!!

Sure it won't triple it, it may be another +50% tho, it may be +30% on average and holding those numbers more stable without drops, and that's a big deal. I'm still planning to do the 2.5.4 vs 2.5.5 threads comparison, but it may take more time to do right, and present it. Yeah, I might not need to rush with showing how the state is on 2.5.4, rather wait until both are tested and then show all the results.