[Spice-devel] Performance of Xspice - some results, and a potential patch

[Yaniv Kaul]

----- Original Message -----
> I've spent several weeks analyzing the network performance of Xspice
> against two test cases.  I also crafted a patch which implements an
> alternate mode for the xf86-video-qxl driver that dramatically
> improves
> network performance.
> 
> The two test cases are simple [1]; a script drives either Libre
> Office
> or Microsoft Office 2007.  They have a few minutes of typing, a bit
> of
> graphics (the test case draws a smiley face), and a little bit of
> interaction with the UI.

How are you verifying that the user experience remains the same?
That there is no tearing, distortion, missing elements, etc.?

> 
> For now, I'm focused on measuring network performance; I plan to
> later
> do some analysis to try to get at the quality of the user experience
> as
> well.  Network performance, particularly the total # of packets, has
> a
> dramatic effect on Spice performance over a remote network.

Indeed - but also take into consideration the number of messages (luckily, some of them are aggregated by TCP).
You can use the dissector in Wireshark to see (and count) the number of Spice messages (or add counters in the server, of course).

> 
> For a test involving 5 minutes of light use of LibreOffice, the
> results
> are as follows:
> 
> 		 Packets	  Bytes
> Xspice		148,428		19,647,168
> Tight VNC	 19,980		 4,724,880
> SSH -X		 48,894 	77,733,200
> SSH -CX		 21,445		 5,096,702
> 
> You can see that Xspice network performance is pretty bad.
> 
> This is partly by design; Spice is designed to replicate the
> philosophy
> of the X server, wherein graphics operations themselves - not pixmaps
> -
> are transmitted across the wire.

Which image compression is being utilized? 
Is the caching effective?

> 
> Further, Spice as a whole is really built around qemu and Windows qxl
> running on a local LAN; Xspice is really just an experimental
> feature,
> and I'm pretty much the first person to examine it's network flow.
> 
> However, if I modify the xf86-video-qxl driver to shift modes into a
> render and send mode, whereby only changed pixmaps are sent across
> the
> wire (and that on a periodic basis), I get dramatically better
> results.
>  That patch is attached; these are the results:
> 
> Xspice + deferred_fps  14,910 	2,971,886
> 
> As you can see, with that change, Spice vaults into the lead.

Again - any difference in user experience?
Y.

> 
> The numbers for Office 2007 are somewhat similar, although ssh -CX
> does
> not fare nearly as well.  (The underlying behaviors are quite
> different;
> Office 2007 is surface + render heavy; Libre Office is fill region
> heavy).
> 
> Additionally, I spent a lot of energy trying to decide if this mode
> could be injected into the Spice server itself, where it could
> potentially benefit the whole stack.  I'm grateful to Alon and Soren
> for
> helping me privately with that effort.  However, in the end, I could
> not
> see a path to do this with the kind of tight efficiency that I think
> is
> required.  I had a test case where an ill behaved X application
> (fluxbox) would do 27,000 pixel draws; and I just couldn't find a way
> to
> run those draws through the Spice server efficiently.  My old
> nemesis,
> red_worker.c, defeats me again :-/.
> 
> I also spent some energy experimenting with modes where we kicked the
> spice server into a video streaming mode.  I had only limited success
> with that.  But I did do some analysis that shows that the test case
> (Libre Office) requires about 3,000,000 bytes to stream a high
> quality
> Theora video.  Given that the deferred_fps patch matches that, and it
> is
> much lighter on the CPU, I've decided to not pursue that approach for
> now.
> 
> At any rate, I would appreciate any comments or feedback on the basic
> approach outlined by the patch.
> 
> Cheers,
> 
> Jeremy
> 
> 
> [1] The tests are repeatable, automated scripts, and can be found
> here:
>     git://people.freedesktop.org/~jwhite/spice-measure
> 
> They are not at all user friendly or easy to parse, I'm afraid.  They
> rely on some crude mechanisms (e.g. I have a dedicated machine, and I
> measure bandwidth by sampling ifconfig results before + after).  You
> can
> try it by having the gtk spice client connected to an 800x600 system
> with a minimal window manager, with LibreOffice maximized.  Then try
> running
>   make
>   ./limeasure "spice display 0"
> and don't blame me if it destroys your system <grin>.
> 
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>