Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Minor
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: 0.9.13-incubating
    • Component/s: guacamole-server
    • Labels:
      None

      Description

      guacd currently logs information primarily geared toward debugging issues with the remote desktop itself, but does not log anything which can be used to debug issues with user experience. If a user becomes unresponsive, a message is logged accordingly, but there is no way to know that the remote desktop connection itself was still responsive, that frames are only being withheld due to network conditions, etc.

      guacd should be modified such that user experience and the server-side responsiveness of the remote desktop can be objectively measured.

        Activity

        Hide
        TdSN Thiago dos Santos Nunes added a comment - - edited

        Is possible to put this on the interface? Enable debug by guacamole client and view with this very good graphs.
        And view the network errors is a very good plus.

        Show
        TdSN Thiago dos Santos Nunes added a comment - - edited Is possible to put this on the interface? Enable debug by guacamole client and view with this very good graphs. And view the network errors is a very good plus.
        Hide
        mike.jumper Michael Jumper added a comment - - edited

        I've added a TRACE log level, and messages like:

        ...
        guacd[26565]: TRACE:	Server completed frame 968247885ms.
        guacd[26565]: TRACE:	User confirmation of frame 968247885ms received at 968247907ms (processing_lag=8ms)
        guacd[26565]: TRACE:	Server completed frame 968248118ms.
        guacd[26565]: TRACE:	Server completed frame 968248126ms.
        ...
        

        Pulling the timing information from the logs and graphing each for a test RDP connection:

        Bottom axis is the number of frames rendered at that point in time. You can see:

        1. The client and server stay pretty close to each other with respect to frame time.
        2. The calculated "processing lag" (estimated time spent by the client rendering a frame) is shifted from "round trip time" (total time between the end of a frame and receipt of the client's response for that frame) by a generally-constant amount (the network lag).

        The nice constant shift between RTT and the processing lag approximation makes me happy, as it suggests that those calculations are working exactly as intended. The client takes longer for more complex operations, the server compensates accordingly, and both stay in time with each other, independent of network delays (network latency results only in latency, not reduced framerate/smoothness).

        Show
        mike.jumper Michael Jumper added a comment - - edited I've added a TRACE log level, and messages like: ... guacd[26565]: TRACE: Server completed frame 968247885ms. guacd[26565]: TRACE: User confirmation of frame 968247885ms received at 968247907ms (processing_lag=8ms) guacd[26565]: TRACE: Server completed frame 968248118ms. guacd[26565]: TRACE: Server completed frame 968248126ms. ... Pulling the timing information from the logs and graphing each for a test RDP connection: Bottom axis is the number of frames rendered at that point in time. You can see: The client and server stay pretty close to each other with respect to frame time. The calculated "processing lag" (estimated time spent by the client rendering a frame) is shifted from "round trip time" (total time between the end of a frame and receipt of the client's response for that frame) by a generally-constant amount (the network lag). The nice constant shift between RTT and the processing lag approximation makes me happy, as it suggests that those calculations are working exactly as intended. The client takes longer for more complex operations, the server compensates accordingly, and both stay in time with each other, independent of network delays (network latency results only in latency, not reduced framerate/smoothness).

          People

          • Assignee:
            mike.jumper Michael Jumper
            Reporter:
            mike.jumper Michael Jumper
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development