xpra icon
Bug tracker and wiki

Opened 7 months ago

Closed 7 months ago

#1551 closed defect (fixed)

start-desktop latency very slow vs. start

Reported by: esarmien Owned by: esarmien
Priority: major Milestone: 2.1
Component: server Version: 2.0.x
Keywords: Cc:

Description (last modified by Antoine Martin)

I mentioned this in IRC but I am filing a ticket now with all the necessary info.

Proof of Concept Docker Container: https://github.com/doprdele/start-desktop-xpra-test
DockerHub? built container: https://hub.docker.com/r/esarmien/start-desktop-xpra-test/

Problem:

  • Running start-desktop vs. start results in noticeable increase in latency for the application over HTML5 and XPRA client TCP.
  • As a test, I decided to use 'start-child' with Xephyr and an LXDE session which was faster, on par with average latency I expect from XPRA usage over TCP. However, when I set Xephyr to autoresize && full screen, the same increased latency results as above with start-desktop.
  • Using start-desktop, the LXDE bottom panel and top panel executes but fails to render in the XPRA window or HTML5 session, also the mouse cursor size in the HTML5 is randomly odd. Using start-child, the panel works as expected. Running 'lxsession' in the included container from lxterminal will show this behavior.

Appendix 1: xpra info attached

Appendix 2: Debug info attached

Attachments (2)

xpra-log.txt.gz (127.1 KB) - added by esarmien 7 months ago.
Xpra debug log
xpra-info.txt (28.1 KB) - added by Antoine Martin 7 months ago.
moving large info to attachment

Download all attachments as: .zip

Change History (18)

Changed 7 months ago by esarmien

Attachment: xpra-log.txt.gz added

Xpra debug log

comment:1 Changed 7 months ago by esarmien

I tried to upload the log but it said insufficient system storage. So here it is on my Dropbox:

https://www.dropbox.com/s/lv9osx70n21wdbj/xpra-log.txt.gz?dl=0

Changed 7 months ago by Antoine Martin

Attachment: xpra-info.txt added

moving large info to attachment

comment:2 Changed 7 months ago by Antoine Martin

Component: androidserver
Description: modified (diff)
Milestone: 2.1
Status: newassigned

comment:3 Changed 7 months ago by Antoine Martin

Tried running "startlxde" with latest trunk version and had to change the default vfb size for "start-desktop" in r16086. (was ~ 8kx4k!)

After that, things worked fine, both in the HTML5 and native clients.

Running the HTML5 client with debugging on (enable "debugging" on the advanced tab of the connect.html page), or the native client with opengl enabled and opengl paint debugging (set XPRA_OPENGL_PAINT_BOX=1 or start it and use Meta+Shift+F10 to enable), I can see the paint updates on screen and those are exactly as expected: only the parts of the screen that got updated are being re-painted.
Screen updates are fast.
I did see a keyboard error, r16089 should help us diagnose this better - but I haven't see it since..

I'll try to download the docker image and play with it to see what it does different.

Last edited 7 months ago by Antoine Martin (previous) (diff)

comment:4 Changed 7 months ago by esarmien

Thanks Antoine!

Do you know when the desktop size fix will be backported to the 2.x branch?

Best,
Evan

comment:5 Changed 7 months ago by Antoine Martin

@esarmien: does it help with your problems?
This fix has already been applied to the v1.0.x and v2.0.x branches in r16090.

comment:6 Changed 7 months ago by esarmien

Hey Antoine,

Does this mean I should compile the 2.0.x branch? Just for simplicity I tried installing beta in the container since the latest one was built yesterday but it didn't work

 xpra : Depends: ffmpeg-xpra but it is not installable
        Recommends: python-setproctitle but it is not going to be installed
        Recommends: python-cryptography but it is not going to be installed
        Recommends: gstreamer1.0-pulseaudio but it is not going to be installed
        Recommends: gstreamer1.0-plugins-ugly but it is not going to be installed
        Recommends: python-gst-1.0 but it is not going to be installed
        Recommends: cups-pdf
        Recommends: python-cups but it is not going to be installed
        Recommends: python-pyinotify but it is not going to be installed
        Recommends: python-opencv but it is not going to be installed
        Recommends: v4l2loopback-dkms but it is not going to be installed
        Recommends: ssh-askpass
        Recommends: python-lzo but it is not going to be installed
        Recommends: websockify but it is not going to be installed
        Recommends: sshpass but it is not going to be installed

Best,
Evan

Last edited 7 months ago by Antoine Martin (previous) (diff)

comment:7 Changed 7 months ago by Antoine Martin

Owner: changed from Antoine Martin to esarmien
Status: assignednew

Does this mean I should compile the 2.0.x branch?

Or you can apply the patch to your existing installation.
Or install the beta.

xpra : Depends: ffmpeg-xpra but it is not installable

This package is in the main repository for sure.
The beta repository is a supplemental one.

comment:8 Changed 7 months ago by esarmien

Owner: changed from esarmien to Antoine Martin

Hi Antoine,

Unfortunately this did not fix the problem.

I installed 2.1.

Still seeing similar problems. Increased latency.

root@b9024ee31a4b:/# xpra --version
xpra v2.1-r16085

When I run ‘lxsession’, the panels do not appear, and it is frightfully slow. When not using start-desktop, fast per usual. When I run ‘startlxde’ instead of lxterminal, I just get a big black screen. The desktop doesn’t appear at all.

Tested in both Firefox and Chrome.

Have you had a chance to try the container yet? I can change the Dockerfile to use BETA package if you’d like if it helps your testing.

Last edited 7 months ago by Antoine Martin (previous) (diff)

comment:9 Changed 7 months ago by esarmien

Antoine,

I updated the container to use the most recent BETA so maybe you can duplicate what I'm experiencing.

Best,
Evan

comment:10 Changed 7 months ago by Antoine Martin

Unfortunately this did not fix the problem.
I installed 2.1.

The current beta packages were a bit dated and did not include the default desktop screen size fix. There are newer beta packages now - not sure this will make any difference, but since you're not commenting on the size of the desktop window, it is worth a shot.

Have you had a chance to try the container yet?

Sorry no, my Fedora 26 laptop is having issues running docker. Maybe in a couple weeks when I get back in to the office.
In the meantime, I can only suggest that you use a better supported distro, Ubuntu is very quirky.

comment:11 Changed 7 months ago by esarmien

Hi Antoine,

Thanks. Trying it out now, will let you know. What's the best distribution you think for XPRA? I would love to use Arch Linux because of rolling releases, but, I don't think it is officially supported

Best,
Evan

comment:12 Changed 7 months ago by Antoine Martin

What's the best distribution you think for XPRA?

Fedora because this is what I use every day.

comment:13 Changed 7 months ago by esarmien

Hi Antoine,

I tried the XPRA beta on Ubuntu and it is significantly better (latency) wise, although now the desktop doesn't fill the whole screen and resizing the browser window doesn't resize the desktop window.

So, I decided to try moving to Fedora since it was your suggestion:

  • Latest XPRA of stable shows the same problems -- very high latency -- but, at least there are no errors starting LXDE and the desktop renders fine. Fedora seems like a good choice for running XPRA

-- Then I ran the BETA code, I get the following error when trying to connect over HTTP

0.2', 8080), address=('172.17.0.1', 43096), peername=('172.17.0.1', 43096). timeout=0.1
2017-06-26 16:15:08,803 Error: tcp connection failed:
2017-06-26 16:15:08,804  invalid packet header, HTTP GET request
2017-06-26 16:15:08,804  172.17.0.1:43096
2017-06-26 16:15:08,804 tcp socket: 172.17.0.2:8080 <- 172.17.0.1:43096.close() for socket={'fileno': 15, 'type': 'UNIX', 'family': 'DGRAM', 'timeout': 1000, 'proto': 0}
2017-06-26 16:15:08,804 tcp socket: 172.17.0.2:8080 <- 172.17.0.1:43096.close() done
2017-06-26 16:15:08,898 peer: (0, -1, -1)
2017-06-26 16:15:08,899 peer: (0, -1, -1)
2017-06-26 16:15:08,899 new_connection((1, <socket._socketobject object at 0x7f613a35a6e0>)) sock=<socket._socketobject object at 0x7f61244f11a0>, timeout=0.1, sockname=('172.17.0.2', 8080), address=('172.17.0.1', 43098), peername=('172.17.0.1', 43098). timeout=0.1
2017-06-26 16:15:08,900 Error: tcp connection failed:
2017-06-26 16:15:08,900  invalid packet header, HTTP GET request
2017-06-26 16:15:08,900  172.17.0.1:43098
2017-06-26 16:15:08,900 tcp socket: 172.17.0.2:8080 <- 172.17.0.1:43098.close() for socket={'fileno': 15, 'type': 'UNIX', 'family': 'DGRAM', 'timeout': 1000, 'proto': 0}
2017-06-26 16:15:08,901 tcp socket: 172.17.0.2:8080 <- 172.17.0.1:43098.close() done
2017-06-26 16:15:13,914 peer: (0, -1, -1)
2017-06-26 16:15:13,914 peer: (0, -1, -1)
2017-06-26 16:15:13,914 new_connection((1, <socket._socketobject object at 0x7f613a35a6e0>)) sock=<socket._socketobject object at 0x7f61244f11a0>, timeout=0.1, sockname=('172.17.0.2', 8080), address=('172.17.0.1', 43100), peername=('172.17.0.1', 43100). timeout=0.1
2017-06-26 16:15:13,915 Error: tcp connection failed:
2017-06-26 16:15:13,915  invalid packet header, HTTP GET request
2017-06-26 16:15:13,915  172.17.0.1:43100
2017-06-26 16:15:13,916 tcp socket: 172.17.0.2:8080 <- 172.17.0.1:43100.close() for socket={'fileno': 15, 'type': 'UNIX', 'family': 'DGRAM', 'timeout': 1000, 'proto': 0}
2017-06-26 16:15:13,916 tcp socket: 172.17.0.2:8080 <- 172.17.0.1:43100.close() done
^C
Last edited 7 months ago by Antoine Martin (previous) (diff)

comment:14 Changed 7 months ago by Antoine Martin

Owner: changed from Antoine Martin to esarmien

now the desktop doesn't fill the whole screen

It was much bigger than the screen before, which may have been hiding the panels you were looking for. (and also costing extra bandwidth and latency)

... doesn't resize the desktop window.

There's a ticket for that somewhere.

stable shows the same problems -- very high latency

Please provide steps to reproduce this problem on Fedora and it will get fixed quickly.

invalid packet header, HTTP GET request

My guess is that you don't have websockify installed, or you're running with --html=off.

comment:15 Changed 7 months ago by esarmien

Hi Antoine,

I got BETA working in a Fedora container /w HTML5. Works great, fast, some artifacts after moving around windows that I can make another ticket for. I have confirmed that changing the default resolution does indeed solve the majority of the problems so you can backport it.

It would be great if the desktop size could be modified by resizing the browser window itself, I'll go look for the ticket. We plan on using XPRA as our primary method of acheiving desktop-in-the-cloud at Harvard University/IQSS, replacing NoMachine? NX4, so that would be a great improvement.

You can close this ticket in the meantime. I'll get back to you if I encounter any more problems in the beta branch.

Best,
Evan

comment:16 Changed 7 months ago by Antoine Martin

Resolution: fixed
Status: newclosed

Works great, fast, some artifacts after moving around windows that I can make another ticket for.

Yes please, this should be fixed before the release.
It may be related to the new scrolling code, in which case disabling this feature would fix the paint problems - at the cost of lower performance. (see #1426 for details)

I have confirmed that changing the default resolution does indeed solve the majority of the problems so you can backport it.

This has been backported and will be included in the next round of stable updates, see comment:5.

It would be great if the desktop size could be modified by resizing the browser window itself ...

I can't find the ticket regarding resizing a "start-desktop" session but this one is related: #530 (it predates "start-desktop" and "shadow" sessions share most of the code).
Feel free to subscribe to it, or create a new one and link back. We should be able to get that in 2.1 if you push for it..

Another ticket which is relevant is #56 (so we can resize to any given resolution rather than the set of pre-defined values in xorg.conf)

Note: See TracTickets for help on using tickets.