https://bugs.winehq.org/show_bug.cgi?id=48668
--- Comment #9 from Paul Gofman pgofman@codeweavers.com --- (In reply to Bernat Arlandis from comment #8)
This patch fixes the issue completely. Now the game runs perfectly smooth in online sessions. Big thank you!!!
Here's a Proton build 5.0-7 with both patches applied: http://www.mediafire.com/file/zz1p2kabyt5ffmy/proton_5.0-local.7z/file
These are the patches for reference: https://github.com/ValveSoftware/Proton/issues/1420#issuecomment-639084670 https://bugs.winehq.org/show_bug.cgi?id=48668#c7
I've applied both patches but it's the second one that fixes the multiplayer issue in rFactor2.
Thanks for testing this. Also, the insights provided about the physics the thread and the way to see its load were helpful and made locating the issue much easier than it could be.
Regarding the problem itself, there slow down comes from getsockname() function which is called very frequently by the application, roughly ~800 times per second from different threads. The implementation of that in Wine is rather heavy as it involves querying the network interfaces, so the function can take about solid 2-3ms. Applications usually do not call getsockname() often, so that was never a problem before. The fix to this looks a bit hacky and not fully correct. I am not immediately sure that a small but non-hacky fix is possible, or some much longer solution to optimize getsockname() will be considered particularly useful for upstream Wine.
In the view of that, since there is a contact with the game developer who was so kind to look at the problem from the game's statistics side and to provide us with the helpful information, is it maybe possible to ask him if so frequent use of getsockname() is intentional? I can guess it might needed to track IP address change, but in any case are there any reasons to do it that often? If not, maybe they would want to change it and do it much less frequently? It most likely does not impose a performance problem on Windows, but yet if it is not really needed probably no reason to keep that in time critical threads.