[Spice-devel] Unfair comparisons with RDP

Wed Jun 29 19:33:56 PDT 2011

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.

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