SPICE performance vs alternatives
daniel at pocock.pro
Wed Aug 23 12:52:38 UTC 2017
On 22/08/17 18:29, Mike Gabriel wrote:
> Hi Daniel,
> On Di 15 Aug 2017 16:08:30 CEST, Daniel Pocock wrote:
>> One question I have about this topic: performance
> ... which is the most mission critical topic when it comes to remote
> desktop in general.
>> I've been using SPICE for a few months now and I've noticed a couple of
>> - bandwidth use appears to be too much for mobile data users
>> - latency is not very good (I'm running over SSH)
>> Can anybody comment on how to investigate or improve latency, especially
>> when the whole stack (client, server and guest) are all Debian?
> Latency improvement might not be what you are looking for, I sense...
> (Unless you have latency problems for other services on your network, too).
To avoid ambiguity, I was talking about a perception of latency in the
UI (e.g. slow rendering, slow to react after a click), not network latency.
> Last time I have tried SPICE, I couldn't manage to get it running (on
> Debian jessie that was). So I don't know much about how it feels when in
> productive use.
I'm using stretch for client, physical server and the VM.
> Performance severely depends on the content that goes over the wire
> _and_ the technology that transfers this content. Actually, it depends
> of the optimal combination of these two factors.
I'm usually concerned with text content in terminal windows, an IDE such
as Eclipse and I would also potentially like to see it working for
things like Postbooks.
> Most remote desktop solutions on Linux provide some sort of a
> framebuffered X11 server on the machine that runs the remote session.
> Then there is some way or other to transport the X11 graphics to the
> client side (the protocol). Most mechanism use the DAMAGE extension in
> the Xserver.
> So it all ends up with bitmap fragments being transported whenever they
> change. AFAIK, this applies to RDP based sessions (xRDP server), SPICE
> sessions, VNC sessions, XPRA sessions (XRPA creates a H.264 stream of
> what is going on on screen).
> The great exception here is nx-libs (NXv3 protocol). The NX protocol is
> highly aware of X11 drawing techniques, so it does not send bitmaps-only
> over the wire but a combination of bitmaps and X11 drawing requests. On
> non-client-side-rendering desktops, this performs much better than the
> DAMAGE based technologies.
> The currently only implementation in Debian that uses NXv3 is X2Go. The
> X2Go Server is already in Debian experimental (and I will upload it to
> testing/unstable at the end of September, after a sprint with the X2Go
> upstream people). (The meeting is in Treuchtlingen, Southern Germany,
> not too far away from Switzerland -- hint hint hint). In the Arctica
> Project, we work on some alternative client-server middleware, being in
> charge of session configuration and runtime control. Another product
> using NXv3 is the TheQVD solution by https://qindel.com (my current
> So, personally, I'd suggest to try out other technologies and see if any
> of the other technologies available performs better on a specific
> connection type. For X2Go Server in Debian, I posted a blog article some
> time ago .
I met the X2Go people at Dornbirn last year. September may be difficult
as I already have other travel plans.
Do you want to include some of this information on a wiki page or is
there one already? There is already a brief description of remote
Have you heard any talk about SPICE adopting NXv3 or replicating what it
does or should we raise that with the SPICE developers?
>  https://sunweavers.net/blog/node/55
> pkg-remote-team mailing list
> pkg-remote-team at lists.alioth.debian.org
More information about the pkg-remote-team