Special K

If you do not provide a log, we can not do anything anway. Just saying.

Usual suspects are Tacview and the OH6 Gunner Export

Do you use MSI afterburner? The menu isn't multithreaded, it never was. So you are always on one core. Do you have anything in your Saved Games\DCS\Scripts\exports.lua?

A lot of testers use beast setups. I have a 49 inch, 5120x1440 plus full Winwing setup for instance on the 2D side and a 6 DOF motion rig with Pimax Crystal on the VR side. Other testers have similar setups, winwing is a very common option many have. I haven't seen that and haven't heard that from any testers. I had a user yesterday that has a similar issue. We've not finished investing yet but his issues point to either armory crate or the display link driver. For anybody in here, please provide dcs.log files as per usual. Telling you have the same issue as the OP is very likely not happening. There are a ton of reasons for the above described behaviour that have nothing to do with any screen exports.

Please provide a dcs.log. We can not do anything without it.

No you do not. Your logfile shows core parking enabled. Otherwise I wouldn't have told you 2025-03-20 12:02:25.412 WARNING EDCORE (Main): CPU HAS PARKED LOGICAL CORES (this can be source of stuttering and reduced performance especially on hybrid CPUs with P/E-cores) In addition - this CPU is NOT fully supported on Windows 10. You need to disable all your E-cores on Windows 10. You should better update to Windows 11.

Disable core parking. That causes your issues.

No, your core assignment is all good. Your P-cores are used for rendering already. render cores: {4, 5, 6, 7, 0, 1, 2, 3} You have 6 P-cores in hyperthreading mode, which means that logical cores 0-11 are your P-cores. They are split beween rendering and common pool. The highest performance class is with your logical cores 4-7, which are used for rendering also. Your E-cores (12-19) are used for IO. You might see performance issues due to Tacview, which I would recommend to disable and see if your situation gets better (if it is even bad).

Core parking and core assignment is something different. So for a general E-core CPU (at least the old ones), the E-cores are used as IO-cores, yes. The core parking is more or less something where Windows decides to not use a specific core, which might be right, if you were the Windows scheduler and think you are the boss in town, but with DCS assigning tasks to cores, the scheduler must not do the parking anymore, as this interferes with what DCS does. So you do not want to have the parking enabled.

2025-03-10 08:31:12.481 ERROR ASYNCNET (3476): HTTP request dcs:login failed with error 6: Could not resolve hostname Hast Du schon ipconfig /flushdns probiert und falls das nicht hilft, Dein DNS nach 1.1.1.1 oder 8.8.8.8 umgestellt? Welchen Provider hast Du?

Ah very good, didn't know that. Thought they all go with LPE cores. Well then it is indeed only the wrong scheduling class assignment. The guys are working on it already. Please, always provide a dcs.log. There are multiple reasons why you can stutter. But it is only possible to say something, if we see a log.

Schick mal dein dcs.log bitte.

Schalte mal Dein IPv6 auf Deiner Netzwerkkarte aus und probiere nochmal.

you just need to install this one here https://aka.ms/vs/17/release/vc_redist.x64.exe That will replace the version you have installed.

Thanks mate. Is this happening during the main menu or during flight?

Have you disabled SMT? Your CPU is missing 50% of your (logical) cores. Yeah I feared it would do that. That's what Intel said how you could figure the LPE cores. Unfortunately it doesn't work. They haven't used any default mechanism that people were using since years, so you need to access the CPU directly, which this program does. Unfortunately the information isn't where they told it should be. From the looks of it, I can't tell you, which of your E cores are the LPE cores. So can't DCS. The only way is using all E cores as common cores and hope that not many tasks get assigned to the LPE ones. Rendering shouldn't be affected from it.

I have not seen a dcs.log of you yet. Ignore the main menu. That is not multi-threaded. Try this and let it run. Curious about the results though. It should only work with Core Ultra CPUs. If it does anyway. cores.py

Hey mate, you sent me a DM that it went away with removing GPU Tweak III? Can you get me a new dcs.log please? Cheers K

Do you have Python on your PC? If yes, I can send you a small script later and we can see if we figure which ones are the LPE cores.

The culprit lies in the E-cores themselves. There are 2 kinds of E-cores now with these CPUs, the old E-cores (now "LPE cores") and new E-cores (which are located on the main package of the CPU and with that much more performant than the LPE cores). In combination with the changes in scheduling (in the past, DCS could just say, the higher the scheduling class, the faster the core), this results into a bad core assignment for DCS. So, you have P-cores that you want to use (probably for rendering), fast E-cores (that you also want to use, probably for the common pool) and slow E-cores (that can be used for IO for instance, if it makes sense due to the low number). Atm, all E-cores (being them fast or not) are being used for the IO pool. That in fact is wrong. It is not that much of EDs fault honestly, Intels decisions are quite frankly strange and do look more like as if they gave the task to some young graduate that tries to live out his theoretical dreams than to someone that has any idea of how gaming works. But it is adressed and I am pretty sure the guys will come up with a good idea how to tackle it. For the time being, you can try to disable all but one of your P-cores (or limit them as much as it works) and see if DCS starts to use your E-cores for rendering and common pools also. Maybe a limit of 1 or 2 or even 3 to 4 P cores will do it, unsure honestly. You might see much better results, if you manage to use the (fast) E-cores for the rendering / common pools.

@The_Nephilim I have looked deeper into the Core Ultra stuff and made a suggestion to the developers on how to handle them. Lets see if that works out.

I wouldn't go with their GPUs though. What they lose in GPU marketshare is what Intel loses in the CPU market share (both for a reason).

Well, the problem started with whoever tried to get a nobel price with this new chip design of Intels Core Ultra CPUs... They took some decisions that makes it more difficult for any scheduler to work with. We remember - it took from Windows 10 to 11 to support even P/E cores and it took at least 2 years when Ryzen dropped, to support the new architecture with different performance classes per P-core. And now comes Intel and changes everything again. These CPUs will work great at some point - but not without any change. There have been changes to the Windows thread director already in the recent past to support them better, but that does not help DCS, which decides based on what the CPU returns in efficiency and performance classes and not in what the designer has thought about. That said - I doubt that DCS will support these kind of CPUs good enough in a short time frame, as ED would need to adapt the design decisions of these CPUs, that are weirdly against anything that was built in the past years. One of the main changes with these CPUs is, that the Windows Scheduler per se assigns tasks to the E-cores (which in all fairness are much faster than the previous ones) and only moves them to the P-cores if necessary. So these additional context switches are wanted, and the way of doing that is potentially great for the biggest market for Intel CPUs - the mobile market. The energy efficiency of these CPUs is great. But we are talking about gaming here. Energy efficiency is an unknown word here. That said, you end up with a system that is designed for something that you do not need or want. And that is always a bad start. I have seen tests where people even disabled all but one P core and still got a reasonable performance out of their systems, as the E cores are faster. But that all is nothing you can do with DCS rn. You can not tell DCS to use some of your E-cores for rendering for instance. I wonder if the Core Ultras even shovel the work still first on the E cores when DCS then decides to move it back to the P cores. If that would be the case, then this would create an additional context switch for any task switch, which would be horrible. Unfortunately, i do not have any Core Ultra to test here, but I can see if I can get my 14900 to use some E cores for rendering. If yes, that might be something to test on your side. But as you have asked me - should you go AMD for gaming instead of Intel these days? A clear and fast - Yes.

You're using an OS that is not made for that CPU. The Windows 10 scheduler does not care about your P or E cores and shovels the work onto any of them, independent of their efficiency classes. This is nothing ED can fix and Microsoft decided some years ago already to no longer support these CPUs in Win10, as its EOL was decided already at that point. So the only chance you have with Win10 is disabling your E-cores completely. That is like as if you remove the first 2 gears from your car. One can do that - but that is not what it's built for. I would highly recommend to update to Win11, besides the fact that Win10 will run out of service anyway in October this year. Tools like MSI Afterburner are good to see if there is a performance culprit anywhere in your system. Besides that, I would neither use that nor GPU Tweak from ASUS nor anything else the like. They can do more harm than good. Do the tweaking for your GPU in your Nvidia control panel. There's more or less anyway only 3 or 4 settings you wanna play with.

Yes it is. Lasso tries things based on the assumption that the related program (here DCS) can't do it properly. As shown above, the DCS logic is quite good already, where any additional program might just only add disruption. There is one use case where you might need lasso, if you're still on Win10 on a P/E-core CPU.