[Bug 48668] New: rFactor2 - Physics thread slower on multiplayer mode
https://bugs.winehq.org/show_bug.cgi?id=48668 Bug ID: 48668 Summary: rFactor2 - Physics thread slower on multiplayer mode Product: Wine Version: 5.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: alex.brrsclnt(a)gmail.com Distribution: Ubuntu Created attachment 66525 --> https://bugs.winehq.org/attachment.cgi?id=66525 Steam rfactor2 proton log This bug is created after the one that exists in the Proton github issue tracker https://github.com/ValveSoftware/Proton/issues/245 The game runs fine in single player mode since version 4.11 to the newest versions of Proton, but there is a problem in multiplayer mode that makes the game run slower. We have asked to the game devs in their discord server for some info, try to get some logs of the multiplayer execution, and finally, one dev told us that despite the graphics thread was fine, there is something wrong affecting to the physics thread in the game, and this only happens in online races, so the issue may be in the network code of Proton/Wine. (@leillo1975 tried to run the game in vanilla Wine, and the problem was also there). Is there any way to trace the network execution to find what could be the problem? I added a log file in the proton issue tracker generated running the game with the "PROTON_LOG=1 %command%" but don't know if that contains enough information. Let me know if I can add any other info. Thanks! -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48668 leillo1975(a)gmail.com <leillo1975(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |leillo1975(a)gmail.com --- Comment #1 from leillo1975(a)gmail.com <leillo1975(a)gmail.com> --- As you can see in this videos, our car runs slower than the rest of the online players: https://youtu.be/Xvuqr8q9r-Q https://youtu.be/CEcS-dn6gBI -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48668 Devin B. <devin(a)devinbraune.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |devin(a)devinbraune.de --- Comment #2 from Devin B. <devin(a)devinbraune.de> --- This problem also seems to affect dedicated server performance, where server performance drops significantly with more players, unless network load is reduced by limiting it in software. I found other racing games to have similar issues with online multiplayer. Currently I don't have a test setup to verify but I think I remember a second process next to the rFactor process taking up significant CPU time when network load goes up. This has been an issue since Wine 1.6 for me. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48668 Paul Gofman <pgofman(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pgofman(a)codeweavers.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48668 Bernat Arlandis <berarma(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |berarma(a)hotmail.com --- Comment #3 from Bernat Arlandis <berarma(a)hotmail.com> --- Created attachment 67349 --> https://bugs.winehq.org/attachment.cgi?id=67349 Wine log in the pits in an online session This is a log while in the pits in an online session with the following options: WINEDEBUG=+pid,+timestamp,+loaddll,+process,+thread,+winsock,+seh -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48668 --- Comment #4 from Bernat Arlandis <berarma(a)hotmail.com> --- The way I check the issue: - In the game launcher, choose the multiplayer tab. - Choose a public server with the same version and with a low ping. It doesn't matter that it's empty. - Start the game and hit RACE. - Go to the track pits and hit Ctrl-C. A load-meter will show up in the upper right corner of the screen. The green line is for the graphics thread, and the purple line is for the physics threads. The longer the line is (in the horizontal dimension) the higher the load. So a line that is full width (full horizontal line) means 100% load. When the issue happens the purple line is full width, it means the physics threads are starving. The developers said that the physics threads should be max at 50% in a normal situation. In an offline session, the purple line is less than half the width on my computer. But in an online session it's always full width. I'm not sure what the vertical dimension is, I remember it's something related to the evolution in time, maybe an average. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48668 --- Comment #5 from Bernat Arlandis <berarma(a)hotmail.com> --- Created attachment 67350 --> https://bugs.winehq.org/attachment.cgi?id=67350 Loadmeter showing the issue in an online session Here you can see the purple line showing full physics thread load in an online session. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48668 --- Comment #6 from Bernat Arlandis <berarma(a)hotmail.com> --- Created attachment 67351 --> https://bugs.winehq.org/attachment.cgi?id=67351 Loadmeter showing normal load in an offline session Here you can see what it looks like when it's working properly. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48668 --- Comment #7 from Paul Gofman <pgofman(a)codeweavers.com> --- Created attachment 67352 --> https://bugs.winehq.org/attachment.cgi?id=67352 (hack) Cache last WS_getsockname() result The attached patch makes the purple indicator well below 50% for me in multiplayer mode, and the car seems responding better. I did not test that with the other players in there. Does the patch help with actual multiplayer gameplay? The patch is applicable to both mainstream Wine and Proton. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48668 --- Comment #8 from Bernat Arlandis <berarma(a)hotmail.com> --- 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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48668 --- Comment #9 from Paul Gofman <pgofman(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48668 --- Comment #10 from Bernat Arlandis <berarma(a)hotmail.com> --- (In reply to Paul Gofman from comment #9)
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.
That sounds perfectly reasonable but I'm not sure the developer will be interested on a fix for a platform they don't support. Also, they seem to be putting more effort adding content than improving their software these days. Simracing is a pretty small market, although it's now growing, and the Linux market for a hardcore simulator is even smaller. Some of us want to change that though. Besides, Windows developers tend to see these issues as Linux weaknesses. They may tell us Linux/Wine is broken. The fact is that Windows is performing much better in this case and they could refuse to fix it on this basis. Isn't Wine supposed to work similar to Windows? I'll try anyway, but in case the developer puts it in the long queue of things-we-would-like-to-do-but-never-get-to or simply says no, I'd try looking for a definitive solution. You've made the hard work of pointing at the problem and providing a simple solution that works, I guess we could work from there. Thanks again! -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48668 --- Comment #11 from Paul Gofman <pgofman(a)codeweavers.com> --- (In reply to Bernat Arlandis from comment #10)
That sounds perfectly reasonable but I'm not sure the developer will be interested on a fix for a platform they don't support.
I am not talking about doing anything specifically for Wine / Linux. My point is if the excessively used of getsockname() is not intentional the developers might want to change that regardless of Linux issues as it maybe can help some corner cases on Windows also. In other words, maybe it worth to just let them know. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48668 --- Comment #12 from Bernat Arlandis <berarma(a)hotmail.com> --- (In reply to Paul Gofman from comment #11)
(In reply to Bernat Arlandis from comment #10)
That sounds perfectly reasonable but I'm not sure the developer will be interested on a fix for a platform they don't support.
I am not talking about doing anything specifically for Wine / Linux. My point is if the excessively used of getsockname() is not intentional the developers might want to change that regardless of Linux issues as it maybe can help some corner cases on Windows also. In other words, maybe it worth to just let them know.
I talked to the game developer as soon as you asked me to. They said it's in their bugtracker to investigate. I've seen you've just submitted a patch in the wine-devel mailing list. I think pushing the issue from both sides would be good since there's something going on in that function call that doesn't happen on Windows and it might have unexpected implications for other apps. There might be something fundamentally wrong in the way this function is implemented either by Wine or Linux (unlikely), or it's just that Windows is doing the same caching you've implemented here. Thanks! -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48668 --- Comment #13 from Paul Gofman <pgofman(a)codeweavers.com> --- (In reply to Bernat Arlandis from comment #12) ]
? There might be something fundamentally wrong in the way this function is implemented either by Wine or Linux (unlikely), or it's just that Windows is doing the same caching you've implemented here.
Probably neither of that. Some in depth aspects of socket implementation on Windows and Linux differ, and Wine has to implement certain additional processing in getsockname() to make it behave exactly as on Windows for UDP sockets bound to specific IP addresses (otherwise some apps will be broken). That was not a problem for other applications as getsockname() is not something the applications usually call in their time critical paths. Can you please try the patch which I sent upstream [1] if it is still fixes the car speed? I tested it myself with the load indicator and it looks the same as with the initial version of the patch, but just in case. 1. https://source.winehq.org/patches/data/186770 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48668 --- Comment #14 from Paul Gofman <pgofman(a)codeweavers.com> --- Should be fixed by https://source.winehq.org/git/wine.git/commit/60c8c78015b12493eb3984feef2910... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48668 --- Comment #15 from Bernat Arlandis <berarma(a)hotmail.com> --- Sorry, I'm late but I can confirm the new patch works equally well on Proton 5.0-8 (I forgot to git pull). Now I'm building it for 5.0-9 but I guess it'll be fine too. Thank you again. Really appreciate the time you're putting into this issue. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48668 Gijs Vermeulen <gijsvrm(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Fixed by SHA1| |60c8c78015b12493eb3984feef2 | |9103724a758af Status|UNCONFIRMED |RESOLVED --- Comment #16 from Gijs Vermeulen <gijsvrm(a)gmail.com> --- Resolving FIXED (Comment #14 & #15). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48668 Nikolay Sivov <bunglehead(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |winsock -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48668 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #17 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 5.12. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48668 Michael Stefaniuc <mstefani(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |5.0.x -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48668 Michael Stefaniuc <mstefani(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|5.0.x |--- --- Comment #18 from Michael Stefaniuc <mstefani(a)winehq.org> --- Removing the 5.0.x milestone from bug fixes included in 5.0.3. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48668 madbad82(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |madbad82(a)gmail.com --- Comment #19 from madbad82(a)gmail.com --- Similar to what was reported on comment2, the game itself run fine now but the dedicated server seems to still be plagued by connection issues/latency, maybe related to this bug report. I've tried to host a race with the dedicated server on wine (7.12-staging), everything was fine up to 6 drivers, above that everyone ping started to rise each time a new driver entered the server and we reached 500/600 ping with 13 driver on the server. I could still ping google from the server with low numbers, so I think the issue was not the server connection itself. The ping issue seemed to be strictly related to the number of drivers, since when drivers started to leave the ping decreased up to nomal numbers (30-50ms). I know I was able to host with this same machine on windows races for up to 13/14 drivers without issues in the past. I'm not completely sure yet if the ping issue may be related to the fact that the server was running on wine or due to the recent updates to rF2 that may have increased the connection requirements. Some data about the test: Speed test report from the server: - 50 Mbps download speed and - 17 Mbps upload speed 8ms ping During the test band usage was lower than 2 Mbps upload (download is probably irilevant but just a little smaller). For reference: 4 Gb used out of 12 of RAM CPU at 40% (none of threads were maxed) Any idea? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla