Multiple Slew Functions Erratic Behavior

[FusRoPotato]

There is a problem that has existed for a long while now across many aircraft and systems in DCS. I've often just shrugged this issue off, but after installing a new video card today, I noticed the problem is slightly more pronounced.

Problem:

When slewing, whether it be on an F-16 TPOD, Radar cursor, FC3 Mig/Flanker Radar, A10A Mavericks, Frogfoot or Ka-50 Shkval, many of the sim's systems will lag, hitch or suddenly speed up or slow down making it difficult to control the position. Meanwhile, there are many other systems that seem unaffected, such as the TADS/PNVS, Hornet Tpods, or numerous other screens. 

When holding the controller axis in a position as still as possible, such as full deflection, the motion tends to lose its hitching and erratic behavior and move smoothly. The issue mostly seems to occur when the axis itself is changing position or another axis affecting the slew begins to change. When this change occurs, the motion seems to nearly double in speed briefly.

The problem seems to be worse when using atypical refresh rates and varying styles of vsync. My monitor currently runs at 120 hz, but I have other monitors running at 60. This may be the problem.

Deadzones and curves have no effect on the behavior.

Hardware:

This may or may not be relevant because I don't know how the game itself captures input and translates it into each systems movement. My primary controllers are two VKB Gladiator NXT EVOs. In addition to those, I've tried mapping such controls to a PS3 controller instead with the same results, and also attempted some testing through Vjoy and freePIE just out of curiosity if it could be a resolution or polling rate related issue. It doesn't seem to matter

Previously I was using a GTX1080 and now I am using a 7900XTX. In both cases, I was getting 120 fps, my monitors max refresh. The only difference being a massive change in visual quality and resolution.

My sticks were recently flashed and updated. I am running windows 10 that is also updated.

I have verified that my stick signals are clean and have also tried passing them through vjoy with additional filtering and granularity enhancements to be certain.

Assumptions:

Since there is no change in framerate, I suspect a frame time measurement conflict or error. If any prediction or assumptions are made about controller positions that are based on frame time, that might cause the issue. It's almost as if an 'axis position rate' times 'frame time' is added to the control motion to hide latency, or perhaps some kind of general output motion scaling based on the time between frames. The result I see is very much like that of such system that has the frame time incorrectly measured. This measurement error seems to occur most when the axis value is changing.

Through something entirely unrelated, I had run into a similar mistake of my own because I didn't regulate or dampen thread timing. I had a system that was jumping between about 64 and 666 hz causing a feedback loop to explode, because windows was attempting to do some low energy shenanigans.

Perhaps the game suddenly thinks the frame time is 16.6ms when the axis as recently changed value, then reverts to 8.3ms once held still (the frame time the game is being drawn at).

I don't know if this would need a track. One could just instant action a F-16 or Ka-50 and slew things around. This might require multi monitors at different refresh rates, or have something to do with AMD refresh rate stuff. AMD is new to me but I'm flicking switches trying to see if anything helps fix it.

[Flappie]

Yes, a track would be welcome. Here's a Ka-50 III track. I slew the Shkval reticle and I don't see anything wrong.

Ka-50-3 slew.trk