xpra icon
Bug tracker and wiki

Opened 4 weeks ago

Closed 11 days ago

#2173 closed defect (needinfo)

xpra gui hangs depending on Decoding Latency

Reported by: stdedos Owned by: stdedos
Priority: major Milestone: 2.5
Component: client Version: 2.4.x
Keywords: Cc:

Description

It appears that GUI actions of xpra (specifically, tray actions) are dependent on Decoding Latency. With such high latencies (showed in the attachment), they appear to be "related" to xpra's responsiveness

Attachments (3)

Xpra-latency_cmd_2019-02-24_19-44-13.png (25.5 KB) - added by stdedos 4 weeks ago.
xpra-high-decode_2019-02-25_07-54-57.png (22.6 KB) - added by stdedos 4 weeks ago.
lan100mbps.png (78.7 KB) - added by Antoine Martin 4 weeks ago.
expected performance on 100Mbps lan

Download all attachments as: .zip

Change History (9)

Changed 4 weeks ago by stdedos

comment:1 Changed 4 weeks ago by Antoine Martin

Owner: changed from Antoine Martin to stdedos


High decoding latencies (anything above 100ms) are not normal.
How do I reproduce this?

The decoding latency is not usually interfering with the UI thread, most picture decoding is done in a dedicated thread and only calls back to the main UI thread for doing the actual painting to the screen.
So it is likely that something else is interfering with the UI thread and that this is just a symptom.
Maybe the clipboard? (#2172) Can you try one of the newer (hopefully fixed) builds, or disabling the clipboard and see if it helps?

Last edited 4 weeks ago by Antoine Martin (previous) (diff)

comment:2 Changed 4 weeks ago by stdedos

Client: Xpra-Python3-x86_64_Setup_2.5-r21840, Win 10
Server:

2019-02-23 19:11:01,495 Xpra GTK2 X11 server version 2.5-r21791 64-bit
2019-02-23 19:11:01,496  running on Linux Ubuntu 16.04 xenial

(started with:)
xpra_cmd shadow ssh://user@ip/0 --opengl=no --desktop-scaling=0.75 --webcam=no --speaker=off --microphone=off


Connecting with:
xpra_cmd shadow ssh://user@ip/0 --clipboard=no --opengl=no --desktop-scaling=0.75 --webcam=no --speaker=off --microphone=off

does seem to fix the issue, but, it is still outside of your "expected delay" (see new screenshot).

I haven't done anything per se, except keep up with the beta builds (server/client). If there is any profiling build, I'd be happy to run a test run with it (or maybe some -d flag?).

Changed 4 weeks ago by stdedos

Changed 4 weeks ago by Antoine Martin

Attachment: lan100mbps.png added

expected performance on 100Mbps lan

comment:3 Changed 4 weeks ago by Antoine Martin


I haven't done anything per se, except keep up with the beta builds (server/client).
If there is any profiling build, I'd be happy to run a test run with it (or maybe some -d flag?).

The values are so far out of whack that something fundamental must be wrong. I just don't know what and I don't think profiling would show it.

This is what you should be seeing (captured on a 100Mbps LAN):
expected performance on 100Mbps lan

comment:4 Changed 4 weeks ago by stdedos

On the shown scenarios it's not 100Mbps LAN.

The first one, is WiFi-over-4G
The second one, is a wired 10Mbps over Internet.

Both connections are crossing IPSec VPN.

However, I assume that "decoding latency" metric is unaffected even by delay in packets delivery.

(I do need to note, however, I have no idea what 36.991 / 4.295 ms latencies are. Numbers seem exceedingly big, and I'd say unexpected. Server never crosses 4 load (on a 8-CPU system), and client appears also "unloaded")

Last edited 4 weeks ago by Antoine Martin (previous) (diff)

comment:5 Changed 4 weeks ago by Antoine Martin

monotonic clock problems could explain some, but not all, of these problems: #2178

comment:6 Changed 11 days ago by Antoine Martin

Resolution: needinfo
Status: newclosed
Note: See TracTickets for help on using tickets.