As part of #619 and #2130, it would help to be able to see how long screen updates take to land on the client's screen. In the same way that we have the "overall latency" on the session info graphs.
r23539 records two new attributes in xpra info:
client.damage.frame-total-latency: how long it takes from the moment we get a damage event until we get the draw acknowledgement packet from the client, that's everything we do - which can be summarized as: batch delay + compression + sending + network latency + receiving + updating the window buffer + sending ack + network latency (again) + receiving ack
client.damage.client-latency: same, minus the connection latency (note: this latency includes the cost of the protocol layer - which is small in most but not all cases..)
As of r23541, these new attributes are now exposed in the perf test data as:
@smo: does that work? Maybe re-run just NODELAY=0 + CORK=0 vs default settings.
Added these to charts in r23546
nodelay0 cork0 vs defaults
Here are the results attached to the ticket.
Something looks off to me what do you think?
debug client frame latency
Something looks off to me what do you think?
Yup. The values are completely wrong: they should usually be lower than 100ms (+network latency).
No idea why. The values are correct when I run xpra info | egrep "damage.frame-total|damage.client-latency" and the perf test code uses the same function as everywhere else for capturing the data:
add("", avg, "Frame Total Latency", ["client.damage.frame-total-latency"])
add("", avg, "Client Frame Latency", ["client.damage.client-latency"])
I've also run the tests and got sensible values out:
Frame Total Latency Client Frame Latency 34 34 43 43 45 45 32 32 77 77 63 63
Can you run again with the patch attached and see what you get? It will dump the values it finds for "Client Frame Latency" as it goes along.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2381