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 _______________________________________________ Spice-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/spice-devel
