Skip to content

Bandwidth and Compute Resource Overlay #1

Closed

Description

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.

Activity

  1. clbr commented on Sep 28, 2020

    @clbr
    Collaborator

    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.

  2. clbr commented on Sep 28, 2020

    @clbr
    Collaborator

    The current cpu formula is:

    • encoding took too long is worth 1 frame points
    • 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.
  3. clbr commented on Sep 28, 2020

    @clbr
    Collaborator

    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).

  4. clbr commented on Oct 1, 2020

    @clbr
    Collaborator

    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.

  5. clbr commented on Oct 1, 2020

    @clbr
    Collaborator

    Hmm, I tested both paths, so I guess it needs more logging.

  6. clbr commented on Oct 2, 2020

    @clbr
    Collaborator

    Not easily. In theory it shouldn't affect it already, but the network code is a bit complex.

  7. clbr commented on Oct 2, 2020

    @clbr
    Collaborator

    Should we use a smaller "recent" value than one minute? 10s?

  8. clbr commented on Oct 2, 2020

    @clbr
    Collaborator

    Logging and the recentSecs = 10 change pushed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions