-
-
Notifications
You must be signed in to change notification settings - Fork 179
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cluttered network doesn't seem to get detected quickly enough for batch delay to compensate. #2812
Comments
2020-06-29 07:04:05: antoine commented
|
2020-07-02 20:55:12: afarr commented
|
2020-07-02 21:39:20: afarr uploaded file
|
2020-07-02 21:40:58: afarr commented
|
I can reproduce problems by starting a connection, then introducing extra latency with ie, from #999:
If the rule is already present when the client connects, then there is no problem and the performance is very good. It seems that we underestimate the bandwidth limit, then a single screen update takes us over the quota:
Then we just throttle too much. With When things are going well - testing with
So, that's doing 60fps video, which is decoded super-fast, so we are hitting vsync. Then when I add the delay with
And things adapt:
One of the problems is that the batch delay keeps going up because the minimum latency value which drives the heuristics becomes a complete outlier. |
OK, got a handle on the bursty behaviour, we wait for pending acks longer and longer and then:
That's 4 frames in just 40ms because the batch delay is actually very low before we start waiting, and then immediately after sending those 4 frames we start waiting again:
The latency is now so much higher that almost as soon as we send a packet then it registers as backlogged.
(that's with 50-100ms delay added each way!) We need to:
|
Difficulty: increasing the target latency improves things when there's jitter but it also makes latency issues harder to spot and the speed / quality / batch delay are not adjusted as quickly. Some updates:
|
2020-12-22 18:33:19: antoine commentedWith the fixes in comment:9 and now also:
With all those fixes accumulated, I am able to run glxgears at only slighly lower fps / quality, despite the roundtrip increasing from 40ms to 150ms! @afarr / @stdedos: sorry it's taken so long.. I've made beta builds you can try, most distros and most branches are covered. (more coming later) |
2020-12-23 00:07:00: stdedos commented
|
This will do for v4.1, will follow up in #3001 |
Issue migrated from trac ticket # 2812
component: network | priority: major | resolution: worksforme
2020-06-19 03:35:37: afarr created the issue
The text was updated successfully, but these errors were encountered: