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

[Yonit Halperin]

Hi,

About the large number of packets: we do plan to aggregate small 
messages together. Your analysis emphasize the importance of it. Thanks!

About the bandwidth: There is one important thing to take into 
consideration - spice stream of messages is not deterministic; it 
depends on the network bandwidth limitation, and on the rendering that 
is done on the server side. If the stream of drawing commands contains 
commands that hides one another, and the hidden commands haven't yet 
been sent to the client, the hidden commands are removed from the queue, 
and the bandwidth usage should turn lower. i.e., if the network is 
unlimited, spice might send every command it reads from the driver 
commands ring to the client, just because it can. But if the network is 
limited, commands will accumulate in the queue, and hidden commands will 
be removed.
However, the information about commands hiding each other exists only 
for commands that haven't been rendered (when commands are rendered,they 
are removed from the tree that represents the order of commands on top 
of each other). Enabling off-screen surfaces increases dramatically the 
amount of renderings on the server side.
I don't know what were the network conditions you tested, but it would 
be great if you could repeat your test with lower bandwidth (you can use 
tc), and also, you can try disabling off-screen surfaces in the driver.

In the same matter, another improvement we planned is to change the 
limit for the size of the queue of messages directed to the client: 
currently it is limited to a constant number of messages. When we reach 
the limit, we stop reading from the driver command ring. We planned to 
change it to use a limit based on the estimation of the total size that 
is pending to be sent to the client. Maybe we should consider limiting 
it by the time duration from the head to tail. In this manner we can 
have more control of the refresh rate, and maybe be able to drop more 
commands than today.

That said, if the scenario is composed of commands that don't hide one 
another, all the above wouldn't help.

Regards,
Yonit.

On 08/06/2012 11:12 PM, Jeremy White wrote:
> 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>.
>
>
>
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>