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