[Spice-devel] Unfair comparisons with RDP

Sun Jul 3 00:38:54 PDT 2011

On 06/30/2011 10:10 AM, Yaniv Kaul wrote:
> On 06/30/2011 05:33 AM, John A. Sullivan III wrote:
>> On Wed, 2011-06-29 at 20:22 -0400, Andrew Cathrow wrote:
>>>
>>> ----- Original Message -----
>>>> <snip>
>>>> Hello, all. I've been using both RDP via TSPlus and SPICE for over a
>>>> week now and the practical world results at least in my mode of
>>>> operation are becoming clear. SPICE does handle major screen refreshes
>>>> better, e.g., monstrous graphics or continuously pasting a full line
>>>> of
>>>> text in a full screen notepad. Of course, SPICE is a clear winner when
>>>> it comes to video though still not practically usable on low bandwidth
>>>> links.
>>>>
>>>> However, RDP is trouncing SPICE in the more common day to day tasks
>>>> involving small screen updates. For example, every time I open or
>>>> switch
>>>> my screen to LibreOffice, the tool bar icons seems to pain one at a
>>>> time
>>>> in SPICE where as they appear all at once in TSPlus. Document
>>>> scrolling
>>>> is more immediate and smoother. Surprisingly, when I open the PuTTY
>>>> dialog in SPICE, it paints in sections whereas TSPlus appears all at
>>>> once.
>>> You'll really need to post some real details here - from versions of 
>>> qemu+spice server that you're using along with the qemu command line 
>>> syntax, host OS, hardware details through to what's running in the 
>>> guest, driver versions, etc.
>>>
>>> I've never seen RDP trounce spice, but if it does, then we need some 
>>> scientific information on the environment so we can diagnose and 
>>> assist.
>>>
>> <snip>
>> Very happy to do so as we really do want SPICE to become our protocol of
>> choice.  I believe I've posted up our details before but will do so
>> again.
>
> Would you be so kind as to capture the Spice traffic (using 
> tcpdump/wireshark) and send it over?
> Specifically:
> 1. Please capture from start - before the Spice client connects to the 
> server.
> 2. Ensure you catch full sized packets (-s XXXX - could be 1500 most 
> likely, when using tcpdump)
> 3. Save into file (-w /tmp/file.pcap when using tcpdump)
> 4. Please compress and send / let me know where I can pick it up from.
>
> I suggest you have only the scenario of connecting to the VM and 
> opening putty, which you complain is slow.
> Hopefully it'll give us some clue.
> TIA,
> Y.

<disclaimer> my Wireshark dissector may be buggy, and I'm basing my 
analysis on it </disclaimer>

Initial thoughts, from looking at the packet capture:
1. Initial image (packet 689) is not compressed using ZLIB (but LZ_RGB). 
Known issue, filed a bug about it somewhere (upstream or Fedora).
2. The same image is actually quite big - 1440x900 - made up of 172 
packets, which took 0.42seconds from the first to the last packets. 
Perhaps splitting it to multiple smaller images would have improved the 
user experience.
3. Next image (packet 967) was also using LZ_RGB, and was quite big 
1440x793 - made up of 157 packets, and took 0.41 seconds from the first 
to last packet.
4. Next image (packet 1023) is nicely compressed using ZLIB_GLZ_RGB. For 
some reason it does not have the CACHE_ME flag set. The next image 
(packet 1056) does have it.
5. Looks like you were not using the guest agent and that effects were 
not turned off? (example, packets 1085, 1580, 1960 which has multiple 
DRAW_FILL commands) - RDP, at least in previous versions, used to 
disable them by default. Can you verify the same settings are used with 
Spice?
6. From packet 1580 and on we see nice use of images from the cache, so 
caching does appear to be working. It is a bit annoying that a 'use 
image from cache' for a 16x16 image takes 75 bytes, but it's the protocol.
7. Nowhere in the stream do I see JPEG compressed images. Not sure why. 
Was it enabled (can be seen in server side logs) ?

Still looking at the capture (and fixing the dissector along the way).
Y.

>> The qemu side is installed entirely from Fedora 15 RPM and unpatched
>> except for Alon's patch to fix the Windows pixel depth problem.
>>
>> libvirt: 0.8.8-4.fc15
>> qemu-kvm-0.14.0-8.fc15.x86_64.rpm
>> qemu-common-0.14.0-8.fc15.x86_64.rpm
>> qemu-kvm-tools-0.14.0-8.fc15.x86_64.rpm
>> qemu-img-0.14.0-8.fc15.x86_64.rpm
>> qemu-system-x86-0.14.0-8.fc15.x86_64.rpm
>>
>> The hardware is a SuperMicro AMD server with two eight core processors
>> and 16 GB of RAM.  Two bonded Gb Ethernet ports provide access to the
>> world while two separate Gb Ethernet ports provide access to the iSCSI
>> SAN using dm-multipath multibus.
>>
>> Most of the testing has been from a Debian Squeeze i386 client running
>> on an Asus netbook to a Windows Server 2008 64 bit server.  The server
>> uses raw partitions presented via iSCSI with the following
>> configuration:
>>
>> <domain type='kvm'>
>> <name>windesk02.pacad.pacifera.com</name>
>> <uuid>70cdeb09-f6b1-6b4d-dc2f-f72c19b9560b</uuid>
>> <memory>4194304</memory>
>> <currentMemory>4194304</currentMemory>
>> <vcpu>2</vcpu>
>> <os>
>> <type arch='x86_64' machine='pc-0.14'>hvm</type>
>> <boot dev='hd'/>
>> </os>
>> <features>
>> <acpi/>
>> <apic/>
>> <pae/>
>> </features>
>> <clock offset='localtime'/>
>> <on_poweroff>destroy</on_poweroff>
>> <on_reboot>restart</on_reboot>
>> <on_crash>restart</on_crash>
>> <devices>
>> <emulator>/usr/bin/qemu-kvm</emulator>
>> <disk type='file' device='cdrom'>
>> <driver name='qemu' type='raw'/>
>> <source file='/download/iso/Win2008Server64R2.iso'/>
>> <target dev='hdc' bus='ide'/>
>> <readonly/>
>> <address type='drive' controller='0' bus='1' unit='0'/>
>> </disk>
>> <disk type='file' device='cdrom'>
>> <driver name='qemu' type='raw'/>
>> <source file='/download/iso/virtio-win-1.1.16.iso'/>
>> <target dev='hdb' bus='ide'/>
>> <readonly/>
>> <address type='drive' controller='0' bus='0' unit='1'/>
>> </disk>
>> <disk type='block' device='disk'>
>> <driver name='qemu' type='raw'/>
>> <source dev='/dev/mapper/iwindesk02-c'/>
>> <target dev='vda' bus='virtio'/>
>> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' 
>> function='0x0'/>
>> </disk>
>> <disk type='block' device='disk'>
>> <driver name='qemu' type='raw'/>
>> <source dev='/dev/mapper/iwindesk02-d'/>
>> <target dev='vdb' bus='virtio'/>
>> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' 
>> function='0x0'/>
>> </disk>
>> <controller type='ide' index='0'>
>> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' 
>> function='0x1'/>
>> </controller>
>> <controller type='virtio-serial' index='0'>
>> <address type='pci' domain='0x0000' bus='0x00' slot='0x09' 
>> function='0x0'/>
>> </controller>
>> <interface type='bridge'>
>> <mac address='54:52:00:02:01:02'/>
>> <source bridge='br0'/>
>> <script path='/etc/kvm/br0/qemu-ifup'/>
>> <model type='e1000'/>
>> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' 
>> function='0x0'/>
>> </interface>
>> <channel type='spicevmc'>
>> <target type='virtio' name='com.redhat.spice.0'/>
>> <address type='virtio-serial' controller='0' bus='0' port='1'/>
>> </channel>
>> <input type='tablet' bus='usb'/>
>> <input type='mouse' bus='ps2'/>
>> <graphics type='spice' port='5900' tlsPort='5901' autoport='no' 
>> listen='0.0.0.0'/>
>> <sound model='ich6'>
>> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' 
>> function='0x0'/>
>> </sound>
>> <video>
>> <model type='qxl' heads='1'/>
>> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' 
>> function='0x0'/>
>> </video>
>> <memballoon model='virtio'>
>> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' 
>> function='0x0'/>
>> </memballoon>
>> </devices>
>> </domain>
>>
>> QXL is compiled from source version 1.4.1.1.  I believe vdagent (version
>> 0.5.1.0) and vdservice (version 0.5.1.0) were compiled from source.  We
>> do have a stability problem with the agent and must regularly restart
>> it.
>>
>> The Debian client was compiled from 0.8.1 source.
>>
>> The client test connections are a multi-Mbps Time Warner cable
>> connection in our test lab and a Verizon 3G Mifi.  The host is in a data
>> center with relatively unlimited burstable bandwidth.  If I recall the
>> messages on stdout from the client, we are typically registering between
>> 4 and 5 Mbps on the cable connection.  Connection to the test lab is
>> over an OpenVPN tunnel.  We have checked for fragmentation and do not
>> see any.  Hmmm . . . there is a possibility the userspace encryption
>> from OpenVPN is getting in the way but that would be a little
>> surprising.  I'll need to activate SSL connections to test that but
>> OpenVPN would be a common usage scenario.  The OpenVPN gateway is a very
>> powerful server that is barely tapped right now.  I've just taken a
>> lengthy packet trace of graphically heavy web sites, streaming video,
>> and switching LibreOffice screens (at which SPICE is strangely bad) and
>> I see sustained throughput of 2.78 Mbps to 4.3 Mbps.  Throughput seemed
>> to be only around 300 Kbps when doing the LibreOffice document switches.
>> Thus OpenVPN does not seem to be an issue; we are able to saturate the
>> cable connection.
>>
>> Please let me know if you need any more information.  We are certainly
>> willing to do whatever we need to do to make SPICE successful for us and
>> for others.  Thanks - John
>>
>> _______________________________________________
>> Spice-devel mailing list
>> Spice-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel