Apparently the terrain engine bug making normandy stutter like this:

Not sure whether or not is this related to the supposable terrain engine bug that was officially mentioned to be behind the VR performance issues, but here is an example of this normandy run where it happened:

Since I got some new goodies with the summer specials, I went and did a fast test, but right off the get go I noticed this and fired up the tools, this isn't from the start of the gameplay, it's some minutes in, after a few such stutters occured. I was playing with Spitfire on a generated mission, which smaller than usual.

Just explaining this for interested people who aren't familiar with such analysis tools: The busiest DCS thread at the top is further broken down to show the amout of work that each module spent in that thread, that's what all the additional color are showing at the top of the colums. You can see when the FPS drop happens in the below GPU Activity graph, there's a big change above, first the other CPU threads don't happen to do much of anything, that's isn't necessairly the problem, even if the other threads were active like they were before the FPS drop it may not have made a difference, it's all about how much over the budget of one core a thread gets and how much of that work is required for engine to run. The other threads probably depend on the main thread to give them work as the engine needs to deal with something pretty big in edterrain4.dll. While the important part of looking at this graph is that the main thread completely saturating one of the cores on this particular CPU which in this case is a Quad Core without SMT/HT enabled 100% divided by 4 is 25%, but it is more important to to note when looking at the main thread in the per-module mode you notice how the amount of work edterrain4.dll is doing when the FPS drop happens in comparison with the rest of the time, that proportion is quite big. to how much edterrain4.dll was working at the time and the complete lack of other module's work in that same thread, edterrain4.dll being the highlighted dark-red colored bar (which is why other colors look a bit greyed out)

But the fact that other threads are stalled and not doing anything during that time reinforces the suspicion this is a bug and not some required calculations for the proper simulation, if that was the case the other threads wouldn't be stalled normally, ofcourse that wouldn't mean it's really a valid amount of calculation but these are some of the ways one could figure out what is a valid slowdown and what is a bug/optimization issue.

One thread can only go up to 25% here as that's where it saturates one hardware core on this CPU, these graphs work to show things ontop and hence another thread that can use other CPU cores is shown stacked up that's, , i could have for example removed those from showing, but for this purpose it's necessary to keep things for proper context, depends on what is being analyzed so it may sometimes be okay to remove things for better clarity and only see relative to that area, this is ofcourse relative to DCS.exe process as all other activity from +30 processes are removed from these graphs, but they were all idling in this test (no recording).

Now, this graph does not include a per-CPU-core column, this is on purpose,it is where the thread bouncing thing comes in, but it doesn't come in literally ... what we do here is simply ignore the bouncing(scheduling), if the scheduling is correct and as optimal as it can be it won't matter how much the each thread was on CPU0 or how much it was on CPU3 during any of this, because on thread can only run on one CPU at a time and other threads won't be in it's way, it be in-theory the same as if these threads were on their own CPU cores, but let's leave those small "load balancing" cache/optimization differences aside now because that isn't a done debate and the industry has nothing to show, only a bunch of claims. Showing per CPU would make the graph far harder to interpret as well as it would be much more complicated for no reason, so sometimes things work so interesting indeed, all that crazy brainstorming (and I have a few regrets how it was done) I did a year ago in that thread was kinda needed just to learn how to use these analysis tools and how to properly present data so it can be accurately shown for the relevant area we're trying to troubleshoot.

Per-CPU-Core analysis would ofcourse be a good way to look for scheduling issues, where quite busy threads would be scheduled to execute on one CPU, none of that would be DCS area of responsibility tho unless some kind of freak bug messing with the OS, to remind everyone of that point that would all be down to either or a combination of hardware, firmware, manufacturer, drivers and the operating system.

The FPS not only drops down to zero, this wasn't just a stutter it's quite a freeze, but it's an extreme case, usually they don't last as long or so severe so I caught the worst example, you can see there's a smaller one right after it, it kinda happens every 2-3 minutes but also can do more in one minute, but later it kinda stopped it went for 20 mins straight without anything, might be something specific some units are doing when interacting with terrain when there was less action.

This is 2-5-4 Release version ... which is current at the time of this test and writing, that bug might have been fixed in 2.5.5 OB but I don't know yet, I might consider switching when I'll do some more testing, but want to first do more stuff queued on Stable, don't have space for both version ( I could make space, but don't want to bother with it as I had big motherboard sata port issues, PC is all full of disks anyway)

If it's related to the VR one and fixed already then no prob, this is just for reference then and for anyone interested to see it how it looks like in the graphs.

EDIT: THIS IS NOT VR - THIS IS NOT VR - It's 1440p on high settings.