darkman222

You have a pretty similar PC as me. Try the following. Download process lasso. And disable hyperthreading as shown in this image: Restart DCS and see if DCS CPU affinity gets these CPUs tagged like that: For unkown reasons you can not achieve this by disabling the efficiency cores and hyperthreading in BIOS. Also starting DCS with the "affinity" argument does not work. Let me know if that helps. If you want to know more about what I found and tested already about the micro stutters look in my thread about it here. Like I said. If you tried it ( process lasso is free) please let me know.

I am aware of that textures loaded from the SDD into RAM also can lead to stutters. ( 64 GB memory are ordered btw) But in my testing, you can see in fpsVR that my memory is way below the limit and no factor. @BIGNEWY@Lord VaderI waited a few updates now for a final test and some conclusions here. My test is like it was from the first time I started testing: Approaching a Gazelle over the ocean. (see the video above how I do it, you can also download a track file of it) I could have used another aircraft to fly close to, but the Gazelle seems to have the biggest impact on CPU frame time and texture loading and unloading. Here are my inital tests about in which version the issue has emerged. I used the DCS updater to revert to older versions. So its all with the same hardware and drivers. Tested on the same day. No change in hardware or drivers affect that test this way. Note: In fpsVR see the graph for individual CPUs, that with 2.9 DCS seems to start using the CPUs more evenly than it used to in 2.8. More about it towards the end of my test. This leads to another test how to improve that behavior. A lower texture size of course helps people that are affected by it, but as long as the texture slider is for all textures, including cockpit textures, it does not help in the long run as long as we dont get separate sliders for cockpit and exterior textures. I still wanted to share my test up to this point as this might give some further insight, without being a solution though. Here comes my most important test. I was trying a method mentioned by Jabbers in his testing running DCS with arguments: --affinityF (4 cores) to --affinityFFF (12 cores) That did not help in my case. It made DCS run unstable. Possibly because it disables random cores. Then I used process lasso and clicked "disable hyperthreading". That also disabled the efficency cores. Note, this only works with process lasso. Disabling the hyperthreading cores and efficiency cores in the BIOS also leads to an unstable running DCS and even the entire PC runs unstable. The only way to do this is with process lasso. Now DCS runs only on these cores ( note the efficiency cores are also disabled) : Now here are the results. The stuttering because of textures loading and unloading into the cores / threads is completely gone. I tried ( multiple times, but without success) the MT.lua @BIGNEWYposted in the thread he started called: "Intel hybrid CPU Getting stutter? Please try this in multithreading DCS" but it did not help. Not sure if it was rather to fix core parking issues. Also it took me this long to figure that solution out because disabling cores via BIOS is no stable solution. Sorry for the long post. But I felt that I needed to share these results in detail, as I spent quite some time gathering them. I included a ZIP file of my system specs, a dxdiag and a dcslog with "allcores" and with "8cores" in the file name. So you have a file that was created using all cores and a file that was created when DCS just used 8 cores. As requested, I included my GeForce settings too. But I dont thing they matter and they are just the plain default anyway. Also a track file is attached. I am not really sure if you can reproduce it on your systems as this behavior is barely visible with the DCS fps graph when trying this in 2D. Running DCS on a high resolution VR headset is of course demanding for the hardware and clearly shows if something is not running smoothly. I am willing to help with further testing for ED, trying LUA files or whatever needed. For now this is a satisfying solution as long as nothing changes and I can keep the performance using this core affinity with process lasso. dxdiag_dcs_log__geforce_settings_hardware_darkman222.zip stutter8cores.trk

Not only the target designator box in NAV or Missile mode have low refreshrate. Also the target designator circle in STT DGFT mode has it. ( see track replay) So if you go for footage on youtube with the NAV mode selected, you will of course just find footage with less erratic movement of the jet for NAV mode. But here is a good one at 9:27 with the target designator box: Easier to find footage of the target designator circle for DGFT mode. You can see, neither in NAV nor in DGFT mode the refreshrate of the TD box or circle is so low refreshing as the DCS TD box is. TD box and circle low fps.trk

@Stroke 3can you reproduce the last one in a single player track replay? Might be related to my thread about the gun pipper with bad refresh rate which is permanent and not only occasional. My thread has been locked December last year, although it is shown as investigating and reported, the issue never has been adressed since now. Also me and other people recognized that the HUD ladder and FPM have some jumpiness since the last update. But very rarely and not reliably reproduceable tho. Seems like the bad refresh rate HUD symbology makes it way into more HUD elements with every update.

Thank you Mbucchia. Although Varjo Base now shows the desired stereo render method, the performance to quad view did not change. Unfortunately the performance of OpenXR compared to OpenVR with SteamVR is in general worse with more microstutters. ( In contrast to that OpenXR on the Pimax performs better than openVR) Should not native OpenXR on the Aero also deliver superior results compared to OpenVR? Application CPU and GPU are well below 11ms frame time. If I am not mistaken I need 11ms for 90Hz refresh rate. Why does it give that microstutters. The frame rate just goes up and down from 89 fps -> 91 fps and down again. See that with openXR and SteamVR the graphs are more stable. Except some spikes there is a steady 90 fps in the GPU graph. I was hoping to gain performance with openXR, but the opposite seems the case. Its the F16 freeflight mission, I always use for testing.

I tried it. Half a year ago. I play a lot of dogfighting in DCS. And with quad views the labels seem to be rendered only in the high res image. As soon as the label goes into the low resolution area it disappears and I see that. Also due to heavy head turning, the headset slips and eye tracking is lost. Also I can see the high resolution rectangle follow my eye movement, which is distracting. But it might serve well outside of the special dogfighting needs It seems like the quad views have more performance impact without DFR than the regular performance you'd get with openVR through steamVR. But as my other test seem to show, in general openXR has higher performance than openVR. So I just need to get rid of the Quad Views to compare both. I did not think of it earlier, because I did not realize, due to Varjo Base update, or DCS updates I just did not get the Quad views displayed on the monitor any more, so it seemed that OpenXR performs worse than OpenVR, which seems not to be the case and I want to investigate it now.

Well, okay. The test with the Pimax helped me to find what might cause my Varjo Aero to show the opposite behavior. Right now I realized that with the Aero using steamVR it uses Stereo (2 views) to render: But when I switch to openXR it uses Quad views. I guess thats the reason the Aero performs worse with OpenXR Is there a way to make in render only in stereo (2 images) with OpenXR as I dont want to use Dynamic Foveated Render due to various reasons?

As title says. It seems like the Varjo Base software comes with an openXR hook for DCS. I havent looked into that for quite a while. I was using SteamVR instead all the time as VarjoXR solution had lower performance. I have a Pimax Crystal too. And I just did a quick test on my other PC with it. Seems like using PimaxXR has 30 percent performance boost compared to the use with SteamVR.

Was that an AI or a human opponent? As if it would not be enough that AIM120 can be fooled with barrel rolling, I hope 9X dont start to fall for the same trick now

I held that back because I thought it was fixed in the changelog "Fixed: Scan volume twitching around when bugged target near or beyond gimbal limit." being a related issue. But apparently not. I have not tried it with smaller jets, as you would not fly like that behing unless you want to do a buddy AAR Will try it with a small jet next. Reproduction: Lock up an aircraft flying in front of you. Go to Nav or Missile mode. Get closer to it about at 400 ft distance the FCR azimuth and elevation symbols on the MFD and the aspect line in the HUD get twitchy and dont seem to know any more what to display. Short video, and full track attached. As I said, further testing with small jet as target in progress. FCR twitching close targets.trk

Reproduction: Use air spawn (as Maverick is already boresighted) Expected behavior: -move TGP over target, Maverick seeker will follow as expected. -switch station to other Maverick -> Maverick from other station will also look in the same spot. Now the not to expect behavior: -now lock the ground target with the TGP (Maverick MFD screen becomes SOI) -switch station to other Maverick -> Maverick "line of sight" symbol in HUD will move up to the center of the HUD ( Maverick boresight cross position, not ground stabilized) ->TMS down and "line of sight" symbol and Maverick seeker will move down to the target again - switch station back to previous Maverick and the same will happen again. Unless you press TMS down again. See a short video of the unexpected behavior and to watch the full reproduction in the track attached. with tgp locked station changed mav looks straight ahead until TMS down.trk

Wishlist items for me: Get the current F16 in a good shape again considering the buggy already existing systems, before adding any new systems to it. Sorry for the hijack, just to put such wishes in the right perspective.

... as long as the request does not affect game performance...

You can export it to a second monitor and record it. Do you need to record it while flying? Or can you also run a track replay? So you could use the settings layout of MFD + Camera and use a recording software like OBS and record only a cropped area of the sceen with the MFD. Its not the exact thing you want, but at least it works right now.

What youre saying is that the first units are already shipping? I placed my reservation in Febuary ... But if they started shipping its a good sign.

The thing with the F18 is that in a guns only dogfight that thing just points at you all the time. You expect it to have it bled its energy at some point. You take the fight up hill in the F16 but the F18 still follows. WIth the M2K before the flight model update you could do that exact thing. Let it point at you and let it bleed its energy. After the FM update one year ago it also got a nuclear powerplant installed. So what is to question is not the performance of the F16 but the drag modelling of the F18 and especially the M2K with its delta wings, which should be just like an air brake at slow speeds. For comparison you can do it with F15s. It only has the energy to point your nose at you while youre at rate speed twice. After the second time, hopefully defended the gun two gun shot opportunites of the F15 its nose will drop and its payback time for the F16. This is at least my observation on the dogfight servers. Talking about guns only scenarios.

Thanks. Although its related, this does not cause the main issues using the radar in that case. The issue is that while pressing TMS UP and NO RAD is showing the radar is slewing whlile being active to the desired target and auto locks everything that is in its way. Making it impossible to pick specific targets with the JHMCS ellipse. I am not even sure for how long this bug has been around now, but this orignal thread date is from December last year. I also made a report about a contributing issue with the radar always starting an azimuth sweep from left to right when the radar is turned on in another thread. That thread is tagged as "reported" in March 2023. Thats one year and one month now with the JHMCS being unusable. Can these two related bugs be please adressed now? Nobody requests a new feature here. Just requesting to fix what once was working.

As far as I know the bug only exists in the F16 and the F18 as they seem to share some common code with each other. I dont know of other jets from ED that have that issue. It is very annoying that I once purchased an F16 with working STT lock funcionality. Then it was broken, after that it was fixed only to break again after a few updates to stay broken until now. I cant even remember how long that bug is around now and annoying people. Especially in the F16 where the level 5 pipper has a delay until it shows up. I cant count any more how often I could not take a shot with a working pipper while I was just fighting the radar to lock the bandit instead of fighting the bandit. Together with the jumpy pipper that has not been adressed either gun fights in the F16 are like playing poker against the STT radar.

+1 please fix ED

To bump this thread and to raise awareness to that it might be related to the LOD switching which might have been changed from 2.8 to 2.9 Have a look at the thread I created right after 2.9 was released. My latest test was to revert to 2.8 where performance was good. Correct me if I am wrong but if a simple revert to 2.8 gets rid of the stutters, then it's not a faulty driver or Hardware or anything else that suddenly caused the stutters. It's DCS 2.9 only which causes the stutters. I am really sick of comments making me look for the cause on my end. Also comments like it's running fine on a 2d monitor. I am pretty sure it's there too. But people don't notice as 2D stutters are not as obvious.

+1 Until then give https://openkneeboard.com/ a try. You can use it in VR bind it to your HOTAS. Have different folders, a radio log etc. I spend too much time in my life not using it

Which ones are you referring to? I thought ED models only things that data can be publicly accessed.

If you lock a bandit with STT through the JHMCS helmet, in a ratio of about every 3rd lock will be lost showing this behavior. The bandit is not jamming. I was trying to find similarities in the situations where it happens. Thats why I played it back with the radar MFD showing. Also I thought maybe it only happens when the bandit or another aircraft was locked before through STT. But that was not the case either. It can happen with the first lock attempt too. It happens with the clear sky behind so its no ground clutter involved. Also even if it should not be possible to notch a radar against the clear sky, that can not be the case here. There is always a good closure rate when watching the numbers on radar MFD. Note that the radar is not on its gimbal limits either. If you want, try it by yourself. Take one of the track files and take control. It should not take more than 3 or 4 attempts. To summarize: No notch, not jamming, no radar gimbal limits involved. What else can it be? Maybe someone with a fresh eye can watch the video and look for hints what may cause it, by taking a closer look at the radar screen. Hope that its helpful with the radar MFD showing although the cockpit view and the JHMCS is not very sharp that way. I included all the track files shown in the video lock air behind the bandit4.trk lock air behind the bandit0.trk lock air behind the bandit1.trk lock air behind the bandit2.trk

Yes. I am not doubting how the DCS F16 is modelled with the currently available data. I was saying unless, if not out of a sudden contrary evidence pops up, which is unlikely, we need to work with what we have. Thats the whole point of what I try to contribute here is how to get the 21 deg/sec out of the current F16 FM. Trying to point people struggling in the DCS F16 to look into other factors they need to consider other than flying 450 kts circles and wondering why they cant win a dogfight that way.

Yes and here comes all the misconception from. Staying at the "low" 18 degrees per second is only if you are one of the dudes who think if you fly the perfect speed on a horizontal plane of motion, then you'll win with your "not" rate king F16. If youre already on the deck, sure, youre out of options. Or at least you have less. If you want, you can replay my track file against the mig 29 and watch in Tacview for how long and when I hit 21 degrees per second. Spoiler: Its when I dump the nose below the horizon and pull 9G. And luckily my pilot does not black out because g effects is off. So I have the 21 degrees for as long and when I needed them. I would wish someone came up with a unclassified document that the FM of the DCS F16 is wrong and a sustainable 18 deg/sec is too little ( drag?). But until then we have to work with what we have. So forget about winning a fight by sticking to 450 kts and wait until you win a medal.