[Spice-devel] Unfair comparisons with RDP

Thu Jun 30 00:10:07 PDT 2011

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.
> 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