You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is difficult to troubleshoot bandwidth issues versus compute contention issues as they look similar to the user. This is especially an issue when you have a single large central installation with hundreds of users. We should look into using existing mechanisms in the code base for measuring bandwidth issues. We should also find a way to measure compute resources. Optimally, this compute resource measurement should not use system tools but rather calculate based on the time it is taking to encode perhaps. The user should be able to turn this tracking on and it would be sent to the client which would overlay the data on the screen.
almost took too long, within 20% of the edge; worth 0.2 points
Then the sum is divided by the frames sent, scaled to the 10 range, and inverted. If half the frames took too long, it should show 5/10. If all frames are quick enough but close to the edge, it would show 8/10.
231ms is the max delay, not the sum. So that longest frame took 7 frames' worth.
The log file says the stat does adapt, but slowly; I've pushed a commit to make it adapt faster. A straight average over the last minute won't show immediate effects if a couple seconds have jitter, but now it's changed to give recent delays more weight.
Activity
clbr commentedon Sep 28, 2020
Recent is during the last minute, total is during the lifetime of this client's connection.
I suppose we could print the encoding times each frame on the maximum debug logging, but it'll be a lot of output, one line per frame. JSON, ok.
clbr commentedon Sep 28, 2020
The current cpu formula is:
Then the sum is divided by the frames sent, scaled to the 10 range, and inverted. If half the frames took too long, it should show 5/10. If all frames are quick enough but close to the edge, it would show 8/10.
clbr commentedon Sep 28, 2020
Pushed the JSON array format and the debug log print. Please see what it prints on your VM (needs the maximum log level of 100).
clbr commentedon Oct 1, 2020
231ms is the max delay, not the sum. So that longest frame took 7 frames' worth.
The log file says the stat does adapt, but slowly; I've pushed a commit to make it adapt faster. A straight average over the last minute won't show immediate effects if a couple seconds have jitter, but now it's changed to give recent delays more weight.
clbr commentedon Oct 1, 2020
Hmm, I tested both paths, so I guess it needs more logging.
clbr commentedon Oct 2, 2020
Not easily. In theory it shouldn't affect it already, but the network code is a bit complex.
clbr commentedon Oct 2, 2020
Should we use a smaller "recent" value than one minute? 10s?
clbr commentedon Oct 2, 2020
Logging and the recentSecs = 10 change pushed.