[Spice-devel] Traces of performance issues

Yonit Halperin yhalperi at redhat.com
Sat Jul 23 22:33:41 PDT 2011

On 07/22/2011 02:33 PM, John A. Sullivan III wrote:
> As mentioned in my last email, I have taken several traces revealing
> performance issues, BSOD, and lost mouse scroll events.
> Performance still seems to be a function of bandwidth.  We are being
> detected as low bandwidth:
> main_channel_handle_parsed: net test: latency 52.512000 ms, bitrate
> 4826250 bps (4.602671 Mbps) LOW BANDWIDTH
> and
> main_channel_handle_parsed: net test: latency 52.634000 ms, bitrate
> 1980818 bps (1.889055 Mbps) LOW BANDWIDTH
> Yaniv's dissector shows we are using zlib compression.
> However, the bandwidth difference between RDP and SPICE for the same
> activity is startling even when accounting for the roughly 272KB sent to
> determine bandwidth.
> The activity I was tracing was connecting, logging in to a running
> session with Zimbra web client open, creating an appointment, and then
> tagging it.  Tagging is one of those comment events that is noticeably
> slower in SPICE than RDP.
> Here are the redacted notes about each trace to show only the method and
> byte counts:
> Connect to running Windows session via RDP (xfreedrp) and create and tag
> a Zimbra appointment
> xfreerdp -z -x b -d PACAD -f -u uid
> Total bytes to tag: ca. 27.5KB
> Total bytes: 581KB
> Connect to running Windows session via SPICE and create and tag a Zimbra
> appointment
> spicec --host --port 5900 --disable-effects all -f&
> Total bytes to tag: ca. 183KB
> Total bytes: 4083KB - 272K for SPICE ping = 3811KB
> Connect to running Windows session via SPICE and create and tag a Zimbra
> appointment
> spicec --host --port 5900 --disable-effects all -f
> --color-depth 16&
> This differed from all other traces in that it did not login but
> immediately opened to Zimbra web client
> Total bytes to tag: ca. 178KB
> Total bytes: 1911KB - 272K for SPICE ping = 1639KB
> 6.5 times the bandwidth for the identical operation.
> Why such a startling difference? Is this a configuration issue or a
> protocol issue?
> Again, I know little about the technology and even less about the code
> and I recognize that SPICE brings the beauty of portability as opposed
> to RDP or NX.  Nonetheless, I noticed this on the NoMachine site about
> NX which is still our speed champion by far.  It concerns their
> advantages over zlib compression - the type we are using.  I wonder if
> we might be able to learn something from their work.  From
> http://www.nomachine.com/documentation/building-components.php
we don't use Zlib as the first line of compression:
When the bandwidth is not limited we use two methods for compression: 
QUIC & GLZ. They are both lossless. Quic is based on predictive encoding 
and is more suitable for real-life bitmaps. GLZ is dictionary-based 
(LZ), and works better on artificial (less random) bitmaps.
When the bandwidth is LOW, we wrap GLZ encoded bitmaps with ZLIB, and 
when it is possible, we compress bitmaps with JPEG instead of QUIC (more 
cpu, but lossy). We can't always use JPEG, since we perform the 
rendering on the client side, and not all the rendering commands will 
suffer a lossy bitmap.
In addition we use caching of bitmaps.

However, we still have room for improvements. Some are addressed here 

Can you please send the wireshark trace for the tagging events?

> "nxproxy is a "specialized" compressor. By "understanding" the X
> protocol it is able to perform many optimizations on the produced X
> traffic. It adapts bandwidth consumption according to network conditions
> and, by only compressing what is not cached by the remote proxy, it
> reduces the compression overhead to a minimum. By comparison, nxproxy is
> able to consume 1/10th of the CPU used by ZLIB compression built in SSH,
> while still compressing better by a factor of 10."
> I'd gladly take a tenfold reduction in bandwidth.  That would put it far
> under RDP! Then again, perhaps we are already doing what they describe.
> Thanks all and please let me know if you'd like copies of the traces -
> John
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel

More information about the Spice-devel mailing list