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@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel