Could not run with --xpra on Ubuntu 18.04 | Speed up xpra start #167
Comments
|
Thank you for the report!
|
@mviereck why is xpra slow to start? (it shouldn't be - if you want faster startup, use Xvfb instead of Xdummy) |
|
@mviereck, thanks for the quick response. I've put the log file: pastebin.com |
|
@rsuhendro I've found the issue.
@totaam x11docker already uses Xvfb. Me (and x11docker) prefer xpra for several reasons, e.g. graphical cipboard support; however, the startup is time consuming. xpra server command: xpra client command: |
|
Wow, you are GREAT!!! It works. Thanks.. |
With this change: r23025, a default xpra server with only audio turned off and Things that can slow it down:
So if you're seeing a startup much slower than this then I am very interested to know why that is. |
|
FYI: I've created an xpra ticket for this issue: faster server startup |
speed up xpra start with improved logfile check #167
Thank you that you are looking at this! An example command to run Generated xpra server command: Generated xpra client command: Xvfb is started by x11docker before running xpra server. xpra client log: You could try x11docker yourself. It is just a single bash script and does not need to be installed. This runs latest x11docker master version with xpra and executes xterm from host.
The winswitch beta repository currently provides lower version EDIT: |
I don't mind. Your server startup is slow because of the opengl probing. There is a 2 second delay before the line that says
I will schedule some new beta builds tomorrow.
It just prevents the server from doing the opengl probing. It does not change opengl support in the vfb display itself. This data is not actually used for anything directly, it is only shown on the client's session info dialog and included in When the client connects, you are seeing some more delays after Instead of waiting for the server to show |
Sure: Switching to python3 and setting
That probably helps a lot! |
|
Accidently the command above was missing |
Looks like the Debian packages wrongly default to python2: From your last server log:
Most of the server delays have been dealt with already in the xpra ticket: This log doesn't show the If you are absolutely certain that the connection is going to be using mmap only, you can save quite a lot of CPU time and system memory with:
I know I have asked before (can't find where), but isn't there a way of enabling XShm safely? As for the client:
The retry to connect feature has a ticket now - should not be too hard: Not much else that I can see. |
I'll be glad to test it as soon as it appears in the winswitch repository. Current test with:
Maybe I find a way if I investigate further. Docker provides an option
I tried it, but the start takes even longer than before, about 3 seconds more.
With the new delay above the startup of server+client is at about 11 seconds again. |
The buildbot has gone offline, I'll get someone to reboot it tomorrow.
Ouch!
That's very unlikely. That's the 2 second delay that the "noprobe" opengl patch fixes.
I think that the difference comes from the client side. (9 vs 6 seconds)
There is a risk of crash if the drivers are buggy. That's why xpra does a test render in a subprocess before it enables opengl - crashes in that subprocess are detected and we disable opengl, details here:
It is somewhat amusing that the xpra ticket is about shaving off 10ms here and there, but your results are many seconds slower than what I would expect. |
Ooops, I found an important difference: During a kernel update a Xen Hypervisor was re-enabled. I've disabled it and now xpra is faster than before.
Yes, it is amusing, and surprising. I don't have a high-end machine, but it is not that bad.
Can x11docker set it to a harmless value to speed up older xpra versions? |
Parallel start now works:
That won't help. It is the execution of the xprop command that costs time, and with older versions there is no way to skip it. |
|
Test with xpra v3.0-r23052:
Please push it to the winswitch beta repository so I can try it out.
|
Pushed builds for Buster, Cosmic and Fedora 30. For the client startup speed, the main culprits are already recorded in the xpra ticket and most of those will be dealt with before too long. I haven't looked at the server startup speed, but since it is now faster than the client, that's less of an issue. |
Thanks! Now with xpra v3.0-r23061
Surprisingly these changes do not save time. Now the time is at about 7s overall. Two obvious client delays: |
You should wait for the server to print
New notes, client side:
Server side:
The latest Buster builds I have just uploaded should work much better for you. |
|
Great! Much thanks for your effort. The server startup until x11docker now checks the xpra release number. If it is below I'll include a recommendation to update from www.xpra.org once it becomes a stable release.
ok, is implemented now. However, this somehow misses the point of waiting for availability. I'd say, the client should also wait for the socket and repeatedly check for it.
That is no problem. Current environment variables for xpra server: Current environment variables for xpra client: xpraserver.log On a complete tangent: Do you have any thoughts on the Xvfb command? We already talked about |
mviereck
changed the title
I reckon we could still get this number down to around 2 seconds, but this is a case of diminishing returns and I have to move on to other things.
Done:
Not really. The preferred default for Xpra is
|
This to avoid server startup failure on Wayland, compare https://xpra.org/trac/ticket/2243#comment:3
This fixed an issue in previous xpra versions: https://xpra.org/trac/ticket/1469#comment:8
I am not sure about it, too. For sure it doubles the amount of memory needed. Xorg doku: https://www.x.org/releases/X11R7.7/doc/libXext/dbelib.html
XINERAMA is disabled above with -.
X-Resource is disabled, too. So it might be better x11docker enables it.
Of course. Much thanks for everything! |
This bug has been fixed and was only ever present in a very limited set of beta builds. It's best not to force the
Hmm, be careful with overriding the defaults in xpra: this fix had been backported to all supported versions. (and as usual, never applied to the Debian packages since they're never updated no matter what serious crasher bugs are fixed upstream.. because "stable" or whatever silly excuse they're using to justify this awful mess - end of rant)
I was wrong: this is only useful for debugging with |
Thank you for pointing that out!
It seems you misunderstand me: The xpra server crashes if
Thanks! I'll disable it again. |
Sort of. Unfortunately, some distributions have started shipping python3 versions of xpra based on the 2.5.x branch.
Ah, gotcha. We will now override it too: |
I found in https://xpra.org/trac/ticket/1469#comment:10
So x11docker should be safe if it sets But anyway, is there a way to check if xpra uses python3? So far I only find this piece of information in |
Yes.
I can't think of one. Something like this would likely be unreliable: |
Yes, it is unreliable. Currently I can install package Will there be a |
This file belongs in the
Yes.
Yes, developing for wayland is a mess.
I don't understand this bit. |
:-D
Normally x11docker checks the host environment and installed dependencies like If a user wants to run an X application in a pure Wayland environment without Xwayland, xpra will be the best choice. However, x11docker somehow needs to know if the xpra client supports Wayland. Btw., if you like to, you can use x11docker to test out Wayland setups. Or for kwin_wayland: With Wayland on host, e.g. Gnome3: In those setups I try xpra on Wayland, e.g. |
It runs fine with --nxagent, xephyr and hostdisplay. X11docker-gui runs fine with kaptain.
Appreciate for any hint.
Thanks
$ x11docker --xpra x11docker/check
x11docker WARNING: User hendro is member of group docker.
That allows unprivileged processes on host to gain root privileges.
x11docker note: Xpra startup is rather slow. For faster startup
with seamless applications, try --nxagent.
If security is not a concern, try --hostdisplay.
x11docker note: Stay tuned, xpra will start soon.
kaptain: Fatal IO error: client killed
The text was updated successfully, but these errors were encountered: