Special K

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.

a) Are you sure that DCS.getModelTime() has a proper resolution to do frame counts? If that is using os.clock() somewhere in the backend, please keep in mind that the os.clockl() implementation is significantly different on Windows and Linux systems. (EDIT: just checked with the developers - it is not using os.clock()). b) QEMU setup It is very likely that your significantly higher time to process privileged instructions is a result of your QEMU configuration. It is at least nothing that DCS can affect in any way. I would suggest the following: - add prealloc=on to your memory allocation for better performance - add -mem-path /dev/hugepages if you have that configured - add cache=none,io=native to your IO setup to enable direct access, add discard=unmap, if your storage system supports TRIM - your smp 6 does not take the CPU architecture into consideration. If you end up on the wrong cores, you wil have a significantly worse performance. Add something like sockets=1,cores=3,threads=2 (needs to be adjusted to your CPU architecture) to avoid that. - Try adding -cpu host,topoext,kvm=on to help the system pass through more CPU features I know a lot of groups that run their servers on proxmox for instance, without any significant performance issue. In all fairness, the DCS server is usually even a bit faster on Linux based systems than on plain Windows.

Yes, please UNINSTALL the A4 mod, as mentioned before. It causes these issues. @QbanRambo can you please change the title to: F5 crashing game when A4 mod installed

Please provide a dcs.log after such a crash. If you have the A4 mod, remove that please and try without.

Well, we're talking a game here and not a high available banking application. I think an outage once a month is quite a great availability. You do not even get that SLA from any of your internet providers, so you can not expect that from ED also. Anyway, your point is noted, BN already said that the team will look into it. So lets see what comes out of it.

Just checked, we had a total of 6 of these events in the past half year on GS which probably corresponds with the auth server outages that were there.

What you ask for is a change in the game. I even wonder where you see all these session failures you are reporting here? I am admin in 2 of the largest servers (GS and HBCW) and we do not see that at least. I get occasional messages from the other server admins but not on a daily basis or in any means as frequent as you describe it here. And the session token is kept for more than 30 mins already. Each account has multiple session tokens btw. You can run more than one session at a time (one client and up to 5 server sessions on each account).

There is a difference if your server went down or if the master server went down. If your server / network connection goes down, the session is being invalidated, if you do not send heartbeats. This happens after a specific while and is quite normal (session termination). In such a case, when your client (or in this case the server that is a client) re-connects, your session token is invalid, causing the error. This leads to a situation, that you try to talk to the server with an incorrect session token, which would not work. I agree, that if the ED server goes down and there is in fact no session anymore, the error should be different. And I was in contact already with the guys, to look at the reconnect to recover that. What can not happen is that ED has to keep all sessions of people where it is not to be detected if your server has crashed, your network has vanished or you just decided to go on vacation. So the reconnect has to be a temporary solution to either cover singular heartbeat misses or login server outages.