Although at first I felt it was just psychosomatic, I am now convinced (through deliberate experimentation) there is a difference in physics and handling between single-player and multiplayer racing. So, here is my question. 1: Does RR3E attempt to create a "level playing field" by varying the physics time-step to match the least performant competitor's rig? 2: If so, is there a way to disable this behaviour? The details below are how I tested my theory. There is no need to read these unless you are interested and want to try these for yourself. To test the theory I set up some controlled experiments. Note: All tests were performed several times as both out-laps and by putting in five laps before beginning to take notes. In all cases the GPU was locked to 120fps and did not vary from this by more than a single frame with an average framerate in the practice session of exactly 120fps to three decimal places. The CPU (Threadripper 2950X - old but perfect for my own CAD simulation work) was set to a constant 3.65GHz with no throttling on all cores and hyperthreading (SMT) disabled. DDR4 memory was locked to 2999MHz. No form of "Eco" mode is allowed on my rig. Experiment 1: 1: Disabled any and all Windows background services not required to run RR3E. This includes anti-virus and firewall services. 2: Had no other applications running, including browsers and telemetry tools such as Crew Chief and SimHub. 3: Had no GPU or network "enhancement" tools running. 4: Used the same track, with the same car at the same time of day with the same cloud level and same setup in single player and as a single participant on my own server in a PRACTICE ONLY session. The result was small but noticeable differences in both handling and FFB clues as to what was happening under the car between single player and multiplayer runs, with single player being very consistent at all times. Experiment 2: As above but had a friend join me on my server but asked him not to not come out on the track whilst I performed practice laps. The result was somewhat more obvious differences in both handling and FFB clues as to what was happening under the car. Experiment 3: As above, but I asked my friend to do a few practice laps with me. By agreement we stayed on opposite sides of the track as much as possible when circulating. The result was much more obvious differences in both handling and FFB clues as to what was happening under the car but with RANDOM severity at random corners of the track - sometimes a corner would be easy to navigate when pushing, then would become near impossible to push through, only to once again become benign on another lap. As with the tests above, these were tested multiple times by closing down RR3E and beginning the session anew. Experiment 4: As above, but in a league event with observations being made during the practice session and race. The result was as per Experiment 3. Note: allowances were made for typical differences in attitude and track evolution during the race. So I went back to the drawing board and used the sample code to create a small C++ app which simply showed the mean, min, and max telemetry update rates of the shared memory. The app was forced to run on its own core with all other processes forbidden from using the same core using core-affinity to prevent any other process from using it, including Windows itself. Despite the frame-rate being as close to locked to 120fps as is possible, the update rates for vehicle position, suspension, and other key physics data varied wildly (under 60Hz to over 400Hz) depending on the form of experiment listed above. Hence why I asked the questions at the beginning of this post.
What you've been measuring with the shared memory update rate is essentially our logic thread update rate. When the CPU is struggling, the internal physics calculations are still done at 400hz. However, the outwards updates do get slower, so shared memory, and more importantly, FFB updates as well. This scales with the amount of other cars on track, as these all add to the CPU load on the logic thread, which is what is causing the difference you are noticing. There's no hidden intended system, just the consequence of an old single-threaded engine running on a CPU that is definitely not optimized for single-threaded performance. We are actually looking into options to improve this though, optimising and possibly multi-threading the logic thread. So hopefully we can bring that update to you at some point for a more consistent experience
So FFB actually depends on how much your CPU struggles? If it's true, I'm very surprised that no one noticed it before, especially since there's many people who run into CPU bottlenecking.
Thank you for the reply. That does sound very likely as SMT/HT capable processors have never been optimised for single thread processes the way the legendary Q6600 was. For those who do not know, that was the last Intel processor which was heavily optimised for single threaded processes. These days it is the job of the developer to optimise for specific CPU threading models and now for GPU thread synchronisation. If I understand correctly, the suggestion is I am reacting to the change of FFB update frequency depending on current logic thread load. I'll reset to the default FFB settings and see if that helps prevent my overreaction to the feedback. Despite this I have to say RR3E is the king of FFB right now, IMHO. No other game feels as much like I am on a live "rubber" tyre to me. I do not envy you unwrapping a single thread optimised engine to work well threaded! My own team just started again when we had to do this for HST work.