Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

start-desktop latency very slow vs. start #1551

Closed
totaam opened this issue Jun 16, 2017 · 26 comments
Closed

start-desktop latency very slow vs. start #1551

totaam opened this issue Jun 16, 2017 · 26 comments

Comments

@totaam
Copy link
Collaborator

totaam commented Jun 16, 2017

Issue migrated from trac ticket # 1551

component: server | priority: major | resolution: fixed

2017-06-16 13:36:45: esarmien created the issue


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

@totaam
Copy link
Collaborator Author

totaam commented Jun 16, 2017

2017-06-16 13:37:06: esarmien uploaded file xpra-log.txt.gz (127.1 KiB)

Xpra debug log

@totaam
Copy link
Collaborator Author

totaam commented Jun 16, 2017

2017-06-16 13:37:47: esarmien commented


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

@totaam
Copy link
Collaborator Author

totaam commented Jun 18, 2017

2017-06-18 14:23:58: antoine uploaded file xpra-info.txt (28.1 KiB)

moving large info to attachment

@totaam
Copy link
Collaborator Author

totaam commented Jun 18, 2017

2017-06-18 14:25:03: antoine changed status from new to assigned

@totaam
Copy link
Collaborator Author

totaam commented Jun 18, 2017

2017-06-18 14:25:03: antoine changed component from android to server

@totaam
Copy link
Collaborator Author

totaam commented Jun 18, 2017

2017-06-18 14:25:03: antoine edited the issue description

@totaam
Copy link
Collaborator Author

totaam commented Jun 18, 2017

2017-06-18 18:11:13: antoine commented


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.

@totaam
Copy link
Collaborator Author

totaam commented Jun 19, 2017

2017-06-19 13:58:31: esarmien commented


Thanks Antoine!

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

Best,
Evan

@totaam
Copy link
Collaborator Author

totaam commented Jun 19, 2017

2017-06-19 15:37:44: antoine commented


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

@totaam
Copy link
Collaborator Author

totaam commented Jun 19, 2017

2017-06-19 16:16:06: esarmien commented


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

@totaam
Copy link
Collaborator Author

totaam commented Jun 19, 2017

2017-06-19 16:20:36: antoine changed status from assigned to new

@totaam
Copy link
Collaborator Author

totaam commented Jun 19, 2017

2017-06-19 16:20:36: antoine changed owner from antoine to esarmien

@totaam
Copy link
Collaborator Author

totaam commented Jun 19, 2017

2017-06-19 16:20:36: antoine commented


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.

@totaam
Copy link
Collaborator Author

totaam commented Jun 19, 2017

2017-06-19 16:53:18: esarmien changed owner from esarmien to Antoine Martin

@totaam
Copy link
Collaborator Author

totaam commented Jun 19, 2017

2017-06-19 16:53:18: esarmien commented


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](../commit/918a5ac5055401a58eb37fd88ca8473f9961de31)

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.

@totaam
Copy link
Collaborator Author

totaam commented Jun 19, 2017

2017-06-19 17:04:14: esarmien commented


Antoine,

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

Best,
Evan

@totaam
Copy link
Collaborator Author

totaam commented Jun 19, 2017

2017-06-19 17:21:20: antoine commented


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.

@totaam
Copy link
Collaborator Author

totaam commented Jun 19, 2017

2017-06-19 17:59:15: esarmien commented


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

@totaam
Copy link
Collaborator Author

totaam commented Jun 19, 2017

2017-06-19 18:01:04: antoine commented


What's the best distribution you think for XPRA?
Fedora because this is what I use every day.

@totaam
Copy link
Collaborator Author

totaam commented Jun 26, 2017

2017-06-26 17:17:13: esarmien commented


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

@totaam
Copy link
Collaborator Author

totaam commented Jun 26, 2017

2017-06-26 23:14:05: antoine changed owner from Antoine Martin to esarmien

@totaam
Copy link
Collaborator Author

totaam commented Jun 26, 2017

2017-06-26 23:14:05: antoine commented


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.

@totaam
Copy link
Collaborator Author

totaam commented Jun 27, 2017

2017-06-27 02:23:46: esarmien commented


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

@totaam
Copy link
Collaborator Author

totaam commented Jun 27, 2017

2017-06-27 11:41:20: antoine changed status from new to closed

@totaam
Copy link
Collaborator Author

totaam commented Jun 27, 2017

2017-06-27 11:41:20: antoine set resolution to fixed

@totaam
Copy link
Collaborator Author

totaam commented Jun 27, 2017

2017-06-27 11:41:20: antoine commented


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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant