Vertigo72

Thats an interesting result. Impressive max framerate, I guess that vega does work when it can stretch it legs. But your low and average frame rates seem to suffer from either the CPU or possibly the ram?

? Do you mean core affinity for the process was set to only a single core? That doesnt happen by itself, that only happens when you configure it like that. Maybe you may have forgotten you ever did that or you did it inadvertently following someones instructions?

He has never ejected me. Im not even sure where you would change that?

Please read the OP carefully, it addresses both. Vsync should off, both in game and in the driver.

Can anyone with DDR4-3200 try and see if changing dram speed makes any real difference? If you can, set it to 2133 in the bios, and rerun the test. My dram order has been backordered, and now Im curious if its worth spending to replace my current 16GB 2133 with 32gb 3200 or if I just should just add 16GB for now and run everything at 2133 (need the extra ram for other apps, may or may not need faster ram for DCS, I have no idea)

Your settings, and thats why I asked everyone set them to DCS' HIGH preset and 1080p. If you use different settings or resolution, the results will not be comparable and the framerates will not tell us much. I also read elsewhere you need to quit DCS, and delete fxo and Metashader2 folders after changing your graphics option settings, or they may not apply. Didnt make a difference for me, but it might, so its probably a good idea.

Ive been doing a little performance testing with the F14, and I found that even with just a 1070 and at 1080p using the games "high" preset, im utterly CPU bound. Changing the clockspeed of my ryzen 2600X, I get almost perfectly linear FPS scaling. Changing the core and vram speed of my 1070, I get no difference at all. None (I even saw a tiny, and statistically irrelevant increase in performance at lower GPU clocks). I knew DCS was cpu hungry but didnt realize it was this bad. Things will be different in other modules that are less demanding, and they are slightly different once you get off the ground, but the worst framerates are close to the ground, and in the F14, so that is what I focused on. I was looking to upgrade my 1070, but this changed my mind. Its probably a waste of money. If you run a 4k monitor or particularly if you use VR, it could make sense to buy a 2080 or similar highend GPUs, but for 1080p, it seems all your money should be spent on the CPU. Not that money can buy a lot of extra performance there, as more than 4 cores doesnt help, and we've been stuck at 4-5 GHz single threaded performance for quite some time, and likely will remain stuck there for quite some time.

What do you have turned off? It might work opposite of what you think, because I didnt turn anything on or off regarding ejection, and my Jester has ejected countless times, but all by himself.

Why would you? There is nothing to be gained. What little you save in power from disabling (idle) cores, is almost certainly offset by the fact you cant "use" those cores (or rather, that part of the die) to distribute the heat evenly across the entire die. That is why windows shuffles threads across cores. If you think about it, slightly lower hotspot temperature and thus potentially longer or higher boost clocks is not the best use imaginable for having 6 or 8 cores, but at least its better than no use at all :)

This is potentially good news! Being CPU bottle necked, I was worried we where pretty much stuck performance wise for the foreseeable future as cpu's just arent getting significantly faster anymore, all we get is more cores. Single thread CPU performance scaling is all but dead. GPUs do still get better every generation, and because of their parallel nature, can be scaled almost arbitrarily. So being CPU bound, I didnt quite see how we would ever be able to use future next gen super high res VR sets with DCS, or even current ones at good FPS. However, if drawcalls is a significant bottleneck, the Vulkan API may be a game changer. Its supposed to dramatically reduce the overhead for drawcalls by a factor of 10x or more. OTOH, even 130 doesnt sound like a lot. Of course, this is a purely synthetic test that only measures the API calls: https://www.anandtech.com/show/11223/quick-look-vulkan-3dmark-api-overhead But its measuring millions of drawcalls per second. If that is what our CPUs are capable off (doing nothing else) and DCS only does 100s of drawcalls per frame, so on the order of 10000 per second, that still only accounts for less than 1% of the cpu time, and even if that gets sped up by a factor 10x, it wouldnt be measurable. Oh well, time will tell I guess/

You dont. CPU usage is very misleading and borderline meaningless. It shows the average of all 4 or 6 cores, but a bottleneck will form if one single core cant execute one thread fast enough. On a 6 core / 12 thread machine this could look like 8% cpu usage, yet you are completely CPU bound. More over, windows will shuffle threads across cores (for good reason, dont stop this). Assume DCS is only 1 thread that uses 100% of a core all the time, but if windows moves that 10x or 100x per second, on time scales of seconds it may look like all cores are underutilized all the time. Finally there may be limits to the parallelism of the CPU and GPU execution. Imagine a frame is prepared by the CPU, than handed off to the GPU for rendering and while the GPU is doing its thing, the CPU has nothing to do. Lets say it takes equal time on CPU and GPU. You would never see more than 50% utilization on any core on the CPU, and yet you are both CPU and GPU bound. Of course reality is much more complicated than that, but you get the idea. As for GPU utilization; Im not sure what is being measured. I suspect its shader utilization ("cuda cores"). DCS GPU pipeline may not be shader bound, but texel fillrate bound. So that measurement could be pointless too. Instead of looking at utilization rates, its much more telling to do as I did; underclock CPU or GPU. If you see no difference, then the bottleneck is clearly elsewhere. IF performance drops linearly with the underclock, as is the case with my CPU in this test, then you are entirely bottle necked by that component. CPU usage is still low though, because I have 6 cores /12 threads, most of which arent doing anything. Adding more cores, the utilisation rate would drop further, but is going to do nothing to performance. increasing clock speed would result in pretty much linear performance boost. At least in that particular test.

Im not here to criticize the F14. I love it too much :) But it does seem like rendering the cockpit requires significant resources, particularly CPU resources. In external views the framerates are much much better. They may indeed be better than a F18, but the reality is we spend most of our time inside the cockpit and thats where the framerates suffer. And gorgeous as it is, I am curious if you have any insights on why its so cpu dependent? High res textures or high polygon count would mostly stress the GPU, so is it AI, or physics or the modelling of all the internal systems, or is it the rendering pipeline somehow?

Good info. I will rerun the tests after deleting those files. I had already noticed some settings didnt seem to take hold, unless I restarted DCS. Maybe thats not enough. Edit: no difference in my case I cant replicate you vsync problem or alt+enter issue. That does seem to be AMD specific. Its not clear to me if you already tried disabling vsync in the game and forcing it through the driver? I have encountered games/drivers where this was needed or otherwise I would end up with a "double applied" vsync and thus framerates locked to 30FPS. As for your results; assuming things dont change after deleting those files, its interesting you beat me in this test. Clearly its not the RAM. Nor is it the GPU as such. So either it is the core i5 thats faster than a ryzen per clock (which sounds reasonable and I would have expected that, but contradicts some other results posted so far), or perhaps the AMD drivers incur a lower CPU overhead? I guess if we get more results we'll learn more.

No. First of all, windows and your bios will already downclock cores that are not heavily used, so they shouldnt get hot at all regardless of what you set the clocks at. Unless they are actually used, and then, well, you want them to be fast. Besides, even at high clock speeds, an idle core uses very little power compared to one thats actually running a task. More over, if you where to lock DCS to a specific core, that core will get hot which will decrease your boost speeds and may even require downclocking to keep temps and power within specs. If instead you let windows juggle the thread(s) across multiple cores then the heat is spread more evenly across the entire die, giving you a larger surface area and thus cooler temps. TL;DR. Intel/AMD and MS engineers do know what they are doing, and they are doing things for a reason. In fact AMD have gotten so good at it with precision boost, , they basically even made overclocking pointless, the cpu does it by itself, it figures out which cores have the most headroom and prioritizes those for boost speeds. There is almost nothing to be gained. You add better cooling and the chip will run faster, nothing else needed. To some extend this also applies to my nvidia GPU. Not worth the effort, boost speeds actually work to pretty much maximize the available headroom. Sort of takes the fun away but also the tedious testing. Intel still sells chips with some OC headroom, but increasingly its also barely worth the effort.

Interesting. Since I think we can discount the fact you have a faster GPU, we basically get identical performance per GHz for our CPUs. I was expecting recent Intel i5s to have a slight edge over AMD. Now Im even more curious if, or how much RAM speed matters, as you do have faster ram than me.

I did a little extra testing to see how much this scenario is CPU or GPU bound, at least on my system. To check that, I underclocked my CPU down to 2 GHz and measured with and without mirrors CPU clock: FPS no mirrors/FPS with mirrors: 2.0 27 /23 2.5 34 /28 3.0 41 /34 3.5 46 /40 4.0 51 /43 The correlation is almost linear! To double check, I underclocked my GPU as much as Afterburner let me (Ill need to search how to underclock it further) GPU core speed: 1544 51 /44 1709 51 /44 1924 51 /43 GPU Mem: 3500 Mhz 51 /43 4000 Mhz 51 /43 Min clock for both mem and core: 51 /43 No correlation whatsoever. We all know DCS is CPU hungry but I didnt quite expect this. Certainly not with "high settings" Things may be different above land, I will need to test that later, but in this scenario and with these settings, I seem to be 100% "cpu" limited. I put that in quotation marks, because it might be broader than just the CPU, in particular memory speed might be a factor, and I do have some slow leftover DDR4. I have some DDR4 3200 on order, so soon I will be able to test if that make any difference. @Strikeeagle345 I would really love to see exact measurements from you, as you happen to have the same GPU and an intel cpu !

Tracks seem pretty broken even when using the stock module. I tried making a benchmark track just using the Su25, but every time you play it, its slightly different. AA and SAM missiles may show or not show. Sometimes they even dont seem to hit, and a plane that was destroyed by one, during some playbacks will just tumble with no visible damage. Camera switch timings are different. its weird? On the plus side, playing back a track seems to result in pretty much the exact same framerates as when recording it. I think all the ballistics and perhaps even some of the AI stuff is recalculated when playing back a track? Which may also explain why they can be so different. Mirror frame drop is rather inconsistent for me. Sometimes its pretty minor, 5-10FPS, even on the ground (or on a carrier). Other times its huge. Havent found the pattern yet, although generally speaking, up high is indeed less of a problem and it could well be related to how complex the scene behind you is. It could also just be that high up, you have spare cpu/gpu cycles, or maybe even less vram in use? Either way, mirrors are a must for me, especially in the tomcat. I need to be reminded of how cool I look :D

Whoever wrote this: and CPU load increased to an average of 80% with one core at 100%.

I dont really think he has any steering issues. It think he was just trying to align to the catapult shuttle within millimeters, expecting it to connect when he was close enough. In reality he probably was close enough all along, but didnt kneel down, or not far enough. It takes a while. edit: QED :) Also, occasionally I have had issues with the shuttle not being attached. Raising and lowering the front gear again seemed to solve that.

But exciting!

What do you think it tells you? Of course the load will be higher when more frames are being rendered. vsync basically allows both the gpu and cpu to take a power nap when they produced a frame within 16ms. As for disabling turbo and clock scaling, fine, doesnt change anything about my argument. If I cant convince you with words, try clocking your cpu down by 1 GHz. Ill eat your cookie if that doesnt impact framerates. BTW, 80% on a 4C/4T cpu? Wow.. considering how poorly DCS uses multiple threads, you seem to be more cpu bottlenecked than I thought.

That doesnt mean anything. Depending on the cpu, Windows may relocate the main DCS thread to different cores tens or hundreds of times per second; if this sounds stupid, keep in mind the overhead penalty is peanuts on a cpu that does 4 billion operations per second and the upside is an even load and heat distribution which enables higher boost speeds. So its usually a net win. You only get to see average loads on much longer time scales, like seconds, which for a cpu seems like a lifetime, but at any given time, one core could, and most likely is, fully utilized. If it werent, windows would lower its clockspeed. Note that this works different on different cpus. For instance, AFAIK on an AMD ryzen with precision boost, you will usually not see this behavior because it has preferred cores that can boost to higher frequencies. Windows will prioritize those. last point; even if 50% of the time, all your cores would be idle, this doesnt mean you are not cpu bottlenecked. To simplify lets say a frame first has to be prepared by the CPU and is then handed off to the GPU. While the GPu does its work, the CPU would be idle. In this example both would take the exact same time. Increasing your CPU speed will still increase your framerate, even though your average core utilization is only 50%. Reality is far more complicated obviously, but you cant just look at one number and say, my CPU is fast enough, its not the problem.

click the link in his post above. He is perfectly lined up, but AFAICT he hasnt set his nosestrut to kneel. Maybe this helps:

Hmm? The launch bar is automatically lowered but you have to kneel down before you can attach to the catapult. After lining up, press and hold the nose strut lever until its fully down. Then you can attach using U. And its quite forgiving, you can be in front of the shuttle by as much as 5 meter, and it will still attach. I had few issues before even before binding my brake controls :)

Im curious how other CPUs and GPUs perform, particularly with the F14, and you might be too if you are looking for an upgrade, so Im hoping many of you want to do a short simple test and post your results to have some rough ideas. Im particularly keen to find out of there is a noticable difference between AMD and Intel cpu's at similar frequencies, and how AMD GPUs fare compared to otherwise largely equivalent nVidia cards. - Set your resolution to 1920x1080 - Configure DCS graphics settings to the preset HIGH (ensure vsync is off) - Restart DCS, and to be sure your new settings are applied, someone suggested you need to delete the fxo and Metashader2 folders. - in your gpu driver settings, ensure you are not overriding MSAA or FXAA or anything else relevant - Load the "HB Tomcat Defend The Fleet' mission - disable your headtracker, or ensure you are looking straight forward - Zoom out all the way (this lowers FPS and looks silly, but increases consistency) The viewpoint should look like this: The base of the stick should still be in frame - Note your framerates (Lctrl+pause, or use fraps or afterburner to have an averaged value) - Now enable your mirrors ("M" by default) and note your frame rates again. post your results along with your hardware specs. Here are mine: DCS 2.5 open beta 2.5.4.30038 Ryzen5 2600X stock speed, water cooled. 3.6Ghz base clock, 4.2GHz boost, actual clock ~4.1 GHz 16 GB DDR4-2133 Geforce 1070 stock speed M2 NVME SSD Without mirrors: 51 FPS With mirrors: 43 FPS update: Since no one else tested this yet, and I still dont have my ram, I just tried to overclock my old ram. From the default 1066 Mhz (DDR4 2133) to 1200 Mhz (DDR4 2400), which is about as high as it will go. CAS latency only took a small hit. update2: DDR4 3200 arrived Without mirrors: 51 FPS @2133 ram Without mirrors: 56 FPS @2400 ram Without mirrors: 60 FPS @3200 ram CAS 16 Without mirrors: 61 FPS @3466 ram CAS 17 With mirrors: 43 FPS @2133 ram With mirrors: 47 FPS @2400 ram With mirrors: 51 FPS @3200 ram CAS 16 With mirrors: 52 FPS @3466 ram CAS 17