I've added a TRACE log level, and messages like:
guacd: TRACE: Server completed frame 968247885ms.
guacd: TRACE: User confirmation of frame 968247885ms received at 968247907ms (processing_lag=8ms)
guacd: TRACE: Server completed frame 968248118ms.
guacd: 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).