#2381 closed task (needinfo)
add total latency to perf charts
Reported by: | Antoine Martin | Owned by: | Smo |
---|---|---|---|
Priority: | major | Milestone: | 4.0 |
Component: | tests | Version: | 2.5.x |
Keywords: | Cc: |
Description (last modified by )
Attachments (2)
Change History (10)
comment:1 Changed 19 months ago by
Description: | modified (diff) |
---|---|
Status: | new → assigned |
comment:2 Changed 19 months ago by
Owner: | changed from Antoine Martin to Smo |
---|---|
Status: | assigned → new |
comment:4 Changed 19 months ago by
Here are the results attached to the ticket.
Something looks off to me what do you think?
Changed 19 months ago by
Attachment: | test-client-frame-latency-dump.patch added |
---|
debug client frame latency
comment:5 Changed 19 months ago by
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.
comment:6 Changed 18 months ago by
Milestone: | 3.0 → 4.0 |
---|
comment:7 Changed 13 months ago by
Resolution: | → needinfo |
---|---|
Status: | new → closed |
comment:8 Changed 6 weeks ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2381
Note: See
TracTickets for help on using
tickets.
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 ackclient.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.