MoleUK

Yup, I also have an ALC1200 and also experience stutters when players join/disconnect/reslot. However in my experience this has only ever happened on servers using non-dynamic slots, and only when that server is typically experiencing higher load. But it's never been 100% consistent and I have barely been playing for the last 6+ months. I'd be very surprised if it is a problem on the user side (or user side hardware even) rather than something server side or inherent to the game, but with DCS all kinds of weird jank and performance quirks are possible.

It being down to audio driver issues would be interesting. I have seen some users report disabling audio in device manager fixed some freezing issues previously. They were using a Realtek ALC1200. I believe Helldivers 2 recently had stutter issues after updating their wwise audio as well. Windows has always been finnicky with audio stuff.

Yeah imo it's unlikely to make much/any difference. I will note again that servers that use dynamic slots (and only dynamic slots) tend to suffer less from this problem overall I think. On servers that have both dynamic and non-dynamic, while role select is open on the non-dynamic slots you will get stutters when players join/dc. If you switch to the list of dynamic slots, the stutters stop. At least last time I did testing on this. I'm guessing the role select/join/disconnect stutters only overspill into general gameplay when the server starts to chug. Which again might be avoided entirely if the server only uses dynamic slots to reduce the strain when the list refreshes. But whatever way ED have the UI refreshing stuff just seems to be problematic if it's causing hiccups for modern CPU's/servers.

I never did monitor network usage spikes during the stutters when players connect/disconnect/reslot. While I can say that every single person connected to the server gets the stutters at the same time when this is happening (and this has been the case for years), I can't speak to how the severity of the drops might differ between machines. Never tested it. Some hardware/software setups might recover from the stutters quicker tho for sure. Mine are fairly minimal, except when role select is open. If you leave role select open the stutters when players join/disconnect/reslot get way way more severe. Which again says to me it's more about the game itself not being optimised well for long lists or refreshing the UI, in the same way that it really struggles when refreshing the list of MP servers. This is probably completely unrelated and is a shot in the dark, but is there any chance that the machine that suffers more severely from the stutters (the 9800X3D) also have 1-2 CPU cores pegged at 100% CPU load even while idle on the main menu? This is a known bug/issue, but I don't know if it's been connected to actual performance problems directly. If it does show that behavior, please check if your wifes machine suffers from the same bug or not.

Gotcha, got my wires crossed there.

The stutters when players join/disconnect is very intermittent. It will only happen on some servers, and only some of the time. You mentioned using your wifes machine earlier, you might want to try having both machines logged into the same server at the same time if possible. You will likely see them both stutter at the exact same moments. A server like growling sidewinder for example is far less likely to have any of these join/disconnect stutters, but a more busy server like 4YA will have them more often. Particularly if 4YA are still using non dynamic slots, I haven't checked in a while if they're still on the old slots or not.

Oh, and there is one other MP specific stutter bug to be aware of. It was partially fixed earlier this year/last year (it was VERY bad for a while), but it's not gone entirely by any means. Sometimes ground units taking damage from certain munitions (or certain units being damaged at all) would also cause server wide stutters. Mavericks in particular were bad for triggering them. These stutters when ground and naval units were taking fire would also show up in track replays in a repeatable fashion, so it's possible they affected SP just as badly. But generally the more complex the MP mission and the more ground units there are the more the odd performance issues start to stack up. Keep an eye on the chat feed for AI units being killed that coincide with the stutters, as well as players joining/disconnecting/dying. You might see some of them match up.

The X3D's also perform much better at 1% and 0.1% lows. Unfortunately stutters in DCS in VR are notoriously tricky to track down. It can be memory, vram, third party monitoring overlays/apps (CPU temp monitoring, RTSS, MSI afterburner etc), antivirus software, the CPU itself, BIOS settings (or bad BIOS versions), the GPU or specific GPU driver versions, issues in the VR software itself, wireless problems if playing in wireless VR, usb problems if over USB. And then there are the DCS bugs and server side performance issues. That's without even getting started on in-game settings. Just got to go through it all to track them down. It does get frustrating. The stutters when players join/disconnect you can at least rule out as something you can't control. It happens to every user connected to the server when it's happening, not just you.

Possibly. But even 1 CPU core shouldn't be struggling with stuff like this, I suspect it's more a poor implementation than it is a single threaded problem. You can also see the game struggle to update the list of MP servers, and when initially choosing a role on joining a server with lots of slots. And even when you aren't getting stutters when players join/disconnect during general gameplay, if you keep the score tab/player list or role select open you will start getting them when players join/dc. You can see it struggle to update/refresh the player list. Something causes the CPU to come to a standstill or hiccup if only momentarily. They could all be unrelated to eachother, but they all feel symptomatic of a single problem imo.

That's an old bug/performance issue, you can't fix that client side as it's not your hardware that is the problem. ED need to fix it. It can also occur when players die and are automatically slotted into new aircraft, or when they manually change slots. Doesn't happen every time, seems to start happening when a server starts getting overwhelmed. Could also be down to server specific slot blocker stuff as well, but i'm skeptical about that. I took this footage over a year ago (timestamped to show the join/dc/reslot events lining up with stutters), and it was far from the first time that the join/dc/reslot stutter issue cropped up for me. Servers that only use dynamic slots seem to suffer from this issue less often, presumably because the game/server is not refreshing hundreds or thousands of slots every time someone joins/dc's/reslots. Theoretically the game should be more than capable of refreshing a list of slots even if it's thousands of them without a performance hiccup. But whatever way ED implemented it (before dynamic slots were introduced) wasn't designed to handle that many slots in MP, at least at a guess.

The point here is that it can happen with perfect frametimes. The animation errors won't necessarily show up on a frametime graph at all, they will just show visually. Because they aren't frametime stutters.

Just to add, some users report that it happens inconsistently on DCS start. ie starting the game up 5 times in a row will result in mouse polling above 125hz causing problems 3 or 4 times out of 5. Also, reducing the polling rate to 125hz does not entirely "fix" the problem. You will still see the frametime react to mouse movement at 125hz, just not in a way that impacts overall visuals at that point.

It's a consistent problem that has plagued DCS for years. It either happens more often in VR or is more noticeable in VR. Sometimes an external FPS cap can help alleviate or fix it, sometimes not. This video is a good breakdown of the likely problem, being referred to as "animation error" here. Where frametime graphs will be smooth, but the visual jitter is still prominent. In the case of DCS running EDGE, the jitter is constrained entirely to the terrain and the terrain only. So whatever process is handling terrain rendering gets out of step.

You can adjust it client side. Both the font size and the size of the text box itself can be reduced without violating IC. In VR it's almost necessary for some servers, especially Contention.

Bump, as the canopy slider still doesn't seem to have any impact in quite a few modules afaik.

Not if you are hitting max refresh, and not if you are using reprojection. Using VD on my settings and hardware I am either hitting 72fps at 80-90% usage (I try and aim for 72fps, no reprojection with some free overhead), or if things get particularly busy I drop below 72fps and GPU pegs at 98-99% usage. That's expected. VD is far better at just maxing out the GPU load than Meta link is mind, as link likes to cut down to half refresh rate if it can't maintain the full refresh rate even with ASW disabled.

You can monitor GPU usage quite easily and see when it can't keep up. DCS VR being primarily CPU bound hasn't been true for over 2 years, since the introduction of MT. Before MT it was heavily CPU bound while still heavy on the GPU. Now it's vastly more likely to be GPU (or vram/ram) bound, except for unusual missions. Many VR users are also using quad view, which increases the CPU load and decreases GPU load. The only reason quadview gives such performance gains is because we have the available CPU overhead to exchange for GPU gains. Even a 5800X3D which is fairly dated will not struggle to keep up with DCS VR atm for the most part, even with quad view enabled. This is why I've been saying the FPS graph in DCS is misleading, if you've been led to believe you were CPU bottlenecked when you were not.

It's unfortunately not reliable in my experience. If running in VR at 72hz and maintaining 72 fps, and just relying on the games internal FPS cap (or your headsets) it will report as CPU render thread limited as you say. But when the GPU struggles to maintain that 72hz/fps, and you dip below 72, it will still report as CPU render thread limited. Despite the GPU being definitively the limiting factor. Additionally, if you have enabled reprojection and your GPU can;t keep up and you end up at half refresh rate being reprojected to hit 72fps, it will also list you as render thread limited. Despite the GPU again being the limiting factor there. In the same scenario, with NVCP being used to cap the game to 72FPS: when maintaining 72 FPS it will report you as GPU limited. But more importantly, when you dip below 72 if the GPU can't keep up, it will correctly report the game as being GPU limited. With the external cap in place, if you run into main sim thread bottlenecks it will still accurately point towards the main sim thread being a problem. But the render thread will no longer be inaccurately reported as the problem when the GPU can't keep up. Additionally to all of this, DCS' internal FPS cap appears to have frame pacing problems in my experience. This isn't entirely uncommon in games, which is why it's often recommended to use an external tool to cap FPS for better frame-pacing generally. The FPS graph being incorrect could be a quirk of my particular VR setup. Given that Quest/Pico headsets can sometimes run the PC at 99% GPU usage instead of 100%, and use additional encode. Maybe the game is misinterpreting that as having some GPU overhead leftover idk, I don't currently have a wired displayport headset to compare to atm.

Yeah the in-game FPS counter will lie like that. Essentially if it can't tell what is bottlenecking you, it will default to saying the CPU render thread is the problem. Capping the FPS externally via nvidia control panel can change this behavior and get it listing you as GPU limited.

This one definitely isn't fixed, as it routinely shows up when mouse polling is set to above 125hz. But only for some users. I don't know of any fix other than lowering the polling rate for affected users. Though generally speaking, some more CPU intensive games can struggle with polling rates above 1000hz. And mouse polling issues in DCS did seem to disappear for years until it's (somewhat) recent return.

These issues still remain with shadows off afaik. Not just in the F-5 but in many modules.

Settings/Options > Gameplay. It's on the right side of the screen: Spotting dots. Just under labels and above birds.

Yep just gotta hope it arrives in a somewhat timely manner. Some of the assets in DCS (trees in particular were really bad for shimmer) just really benefit from anti-aliasing. It's particlarly bad in VR, where the jaggies are extremely in your face and you have to pump the resolution to absurd numbers to get past it. Or you just enable DLAA and take the tradeoffs. It doesn't help that MSAA has never worked particularly well in DCS in my experience either, some have said it's due to the switch they made from forward rendering to deferred.

J and K both harm the spotting dots considerably with DLSS enabled. Particularly as those dots fly in front of cloud cover, as DLSS doesn't like that contrast at all. With just DLAA enabled, the impact isn't anywhere near as severe. Rolling back to the older non-transformer presets (C or F iirc) will also help the dots appear a bit better, but with obvious visual tradeoffs. Ultimately ED should give us the option to disable DLSS/DLAA from running on the spotting dots altogether, in the same way they have the MFD's. That's the only real 'fix' for this one. In the meantime, try settling for just DLAA. If that's still too negative an impact, go back to MSAA.

Others have run into this problem before. There's another recent thread floating around on it but can't find it. There is also a VR specific problem where the opposite happens, where opening F10 leads to the lighting going way too bright for a while. It appears to be HDR misfiring at a guess. Not the type of HDR found in monitors or in the system settings etc, it's the lighting technique used in gaming to brighten/darken scenes as you transition between light/dark areas. The kind of adaptive lighting/gamma system they have has always had some odd quirks imo, I wish we could disable it in the options.