[Spice-devel] Traces of performance issues

[John A. Sullivan III]

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 172.29.1.133 &
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 172.29.1.124 --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 172.29.1.124 --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

"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