SPICE performance vs alternatives

[Daniel Pocock]

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
>> things:
>>
>> - 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
> sponsor).
> 
> 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 [1].
> 

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
desktops here:

https://wiki.debian.org/SystemVirtualization

Have you heard any talk about SPICE adopting NXv3 or replicating what it
does or should we raise that with the SPICE developers?


> Greets,
> Mike
> 
> [1] https://sunweavers.net/blog/node/55
> 
> 
> 
> 
> _______________________________________________
> pkg-remote-team mailing list
> pkg-remote-team at lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/pkg-remote-team
>