On 07/04/2011 05:21 PM, John A. Sullivan III wrote:
Very helpful and interesting. I'll respond in-line - John
On Sun, 2011-07-03 at 10:38 +0300, Yaniv Kaul wrote:
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.
That makes sense. I was in full screen mode and my screen is 1440x900.
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.
Also makes sense - that was probably the toggle into full screen
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?
That's very interesting. We are but we frequently notice it stops and
fixing it is one of our higher priorities. I'll recompile and see if I
get any better performance and stability. I'll check the effects
settings.
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.
This is a little distressing. I'm guessing those 16x16 images are the
LibreOffice tool bar icons. That part is one of the most dramatically
slower comparisons for SPICE versus RDP. In RDP, they appear all at
once. In SPICE, they paint slowly, one at a time, and perhaps do so a
couple of times over - not sure about that last part but the overall
experience is that it takes not just a little but many, many, many times
longer to paint my LibreOffice screen in SPICE than it does with RDP.
7. Nowhere in the stream do I see JPEG compressed images. Not sure why.
Was it enabled (can be seen in server side logs) ?
I'll have to have a look. I assume one does not have to actively do
something to enable this but rather that it is the default. Is that
true? Thanks - John
JPEG and ZLIB are only recommended when the connection to the client is
limited. They are automatically set on connection if spice identifies it
as slow.
It can be forced by
jpeg-wan-compression=always,zlib-glz-wan-compression=always (default is
auto)
Also, on slow connections, it is recommended to run the client with
--disable-effects=all (if the guest is windows)
This will disable wallpaper, font smoothing, and animation effects on
the guest
<snip>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>
<snip>
_______________________________________________
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
