Special K

Done. This feature was a long asked question from the community. Mod makers are licking their fingers after it. But it comes with a cost. It opens up options that can be critical for the users of DCS World, so ED had to do something. Sure, there are better ways of doing it. But the enhanced security was indeed needed. It is 2 lines you add to your autoexec.cfg, so I am pretty sure one can survive that. And no, I am not going into detail what potential this call has, for reasons.

No it gets added to the pool on startup but might get parked before polled. So when it's needed it might not be in the state is should be causing the stutter until it's unparked again. See it as a database pool where the connections time out after a while but the pool doesn't know about their state. When you're unlucky enough to grab that connection from the pool, the database takes a bit longer to open that connection again as it would on an already open connection.

That's not 100% correct. DCS creates core pools and schedules the tasks in these pools. With that, DCS decides what will be on which core groups at least.

Only because you see the same result does not necessarily mean you have the same root cause. Can you please provide the following: - a recent dcs.log from a gameplay where you had the issue - a dxdiag.txt which you can create by running a Windows tool named dxdiag and press save everything at the bottom. Not sure if I have asked that yet, but you do not start your DCS as admin by chance? If yes, don't do that please. For rebar, yes your DCS will most likely benefit from it. I am not a big fan of staying behind on BIOS updates, as the changes they made usually are fixes to issues they encountered. If they upped some voltage, they probably did that to stabilize something, most likely memory (e.g. better 4 stick support) or the like.

Ok, so additional things. Your BIOS is very (!) old. Please update it to the latest version. Update your chipset drivers also. Some game crashing because of a fixed pagefile is more or less impossible unless the pagefile is not large enough. You need to see "why" it crashes. Second thing I see in your dxdiag is that you run all these ASUS stuff like Armory Crate and DtsApo. If you do not absolutely (!) need them, get rid of them. They are all known to cause a ton of issues. Your last 10 reported system crashes are all in these ASUS programs and probably much more likely the reason for any crashing besides the pagefile (I see not a single sign of such a crash). As BN mentioned already - and sorry for having read the whole convo only now - you want to update to Windows 11. For your settings, please disable hot plugging (in your control options) and disable SSAO. SSAO is known to eat performance. Delete Saved Games\DCS\fxo and metashader2 and run your test again. If it still stutters, send a file named Saved Games\DCS\Scrips\Export.lua (if you have that).

@iceman06 Without having looked at your log yet (which I will do as soon as possible), you are using MSI Afterburner, which is known to be a performance issue on its own. Can you please reconfirm that the issue is still happening, if AB is uninstalled? EDIT: sorry, just saw that you tested without already- I am at work rn, will report back later. In the meantime, please create a FIXED pagefile on your FASTEST NVMe SSD of at least 32 GB in size and retry.

Your system is hard crashing with bluescreens. The DCS crash is a stack issue, which points to a memory issue. Check if there are BIOS / chipset driver updates available for that mainboard. If yes, update. If no or if the update does not help, reduce your memory speed (e.g. disable XMP).

Core parking usually is a cause of stutters, not of crashes.

DCS can use up to 3 threadpools: - Render Pool => your rendering - Common Pool => everything else but IO tasks (probably file and network operations) - IO Pool => probably file and network operations I am not an ED developer, so these are somewhat guesses. Not sure if I asked that already, but do you run DCS as Administrator by chance? Or use the Nvidia overlay?

The first picture is ok, that is expected. The P-cores are being used for the render pool (the ones with the higher scheduling class if available, ED named that performance class for whatever reason) and for the common pool. The E-cores are used for the IO-pool, if there are any. Otherwise, the IO-pool is empty and IO tasks will be handled by the common-pool also. That is then shown in the 2nd picture, where the IO tasks will be spread also over the P-cores and the E-cores will not be used (that dcs.log would probably have shown an empty IO pool).

This is how it looks like (that's my CPU, but it looks similar).

Taskmanager always shows you logical cores. Your CPU has 8 P-cores (each P-core has 2 logical cores) and 16 E-cores, which only have one core. So you have 8 + 16 = 24 physical cores but 8x2 = 16 + 16 = 32 logical cores (aka threads, which is in all fairness wrong but nevermind) So, when you see the first 8 cores loaded, that means that 4 of your P-cores are fully loaded and nothing else. If you can replicate that somehow, I would really love to look at a DCS log for that case.

But how did you manage to get only your first cores used? You must have disabled the other cores (via lasso or TaskManager or Registry)

Can you please stop using process lasso or whatnot to activate / deactivate cores? DCS reads your CPU architecture and assigns specific tasks to specific cores. if you play around with that on your own, you work against what ED is doing for you already.

Can you disable the Nvidia overlay please and see if that changes anything? We had some users where the Nvidia overlay caused exactly that.

Yes, that would be 1.x Your PC crashes a lot in the Gigabyte Control Center with a file not found error. Can you reinstall this software also please? And if you do not necessarily need it - can you just uninstall it? From the DCS log, all I can see which I would disable is civil traffic, the rest looks pretty much ok. The core that you report as maxed out - does that happen in the main menu only or also during flying?

Sorry, just saw it today. You have a ton of memory related issues logged in your DXDiag. And I can not find that BIOS anymore which is usually a bad sign (vendors pull bad BIOS versions). So - try the following: - Update your BIOS to the latest available version. Check your chipset drivers also. - Disable XMP - Try again

But - you can not just put in random GUIDs?? You need the ones that your system gave to your USB devices. My script does the subdirectories also btw. It has been used by a couple of people already without issues.

I would not run a random ChatGPT script that does a simple rename and has 100 lines... You can also just use this: param( [string]$directory, [string]$oldName, [string]$newName ) Get-ChildItem -Path $directory -Recurse -Filter $oldName | ForEach-Object { Rename-Item -Path $_.FullName -NewName $newName } That is a small powershell script, which does basically the same. It runs through your Config\Input directory and renames all oldName files in there to newName. How would you use it after you changed your hardware? - Copy your old Saved Games\DCS\Config\Input folder to your new PC. - Open DCS, go to the plane of your choice. Save new bindings in any of your devices which then gives you the new GUIDs. - Then check the new names and run the above script with the old and new filenames. Depending on the number of controllers you have attached, you run it n times.

Hey mate, all these crash logs are from different timestamps, even different dates. It would be good to have a consistent state of all logs including server logs, so that one can see what happened at the same time

Yes, that seems to be a placebo mate. The binaries in bin and bin-mt are identical. DCS is full MT now since a longer while already. You might want to double check your antivirus. Maybe you have a weird one, and not excluded the whole DCS installation directory but just one executable.

Ok, so first things first - why do you disable 3 of your logical cores? That is 1,5 physical cores. There is literally no reason to do that. Remove the core affinity mask. Then to all other issues: - Your pagefile is too small, you want a pagefile of 32768 initial and max size. - Your DCS is modded, your mods are causing a lot of errors. - The scripts in the mission you are using have a lot of errors (for instance AI_Wingman_v1.0.lua) - One of the above is crashing your DCS. - You should think about disabling Tacview for performance reasons.

No, I do not know of anybody that did such a deepdive into their configuration, mainly because they had no major issues. One of our testers did some performance comparisions Linux vs Windows and came to very good results. I can ask them what exactly they did or ask them to join in here. But I would rather suggest to move this thread from Multiplayer Bugs to somewhere else, as this is a setup issue or VM issue, but not any bug of DCS. If kernel times are high, then the API that DCS uses by itself is slow already, so DCS can not magically speed that up.

They are doing the measures on the VM itself, so I doubt any time drift between the host and the VM would be of relevance. But the VM itself just has too much overhead (here), which causes the longer kernel times.

Yeah, it still only has a resolution of a second. I am not sure, if I would rely on that for any benchmarking.