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

[Jeremy White]

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.

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.

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.

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.

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>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Implement-a-Deferred-Frames-mode-in-which-we-defer-s.patch
Type: text/x-patch
Size: 12789 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/spice-devel/attachments/20120806/b2331638/attachment.bin>