[Spice-devel] Unfair comparisons with RDP

[Yaniv Kaul]

On 07/04/2011 07:33 PM, John A. Sullivan III wrote:
> On Mon, 2011-07-04 at 17:48 +0300, Yonit Halperin wrote:
>> 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>
> Thanks.  All of our test environments seem to quality as limited thus I
> would expect us to always be using ZLIB and JPEG compression.  If
> they're not kicking in, I would suspect we have uncovered a bug.  I
> believe a previous post said a limited connection was anything under
> 10Mbps; our links are well under 5Mbps.

Look at the spice server logs. From the capture you sent me, there was 
not JPEG compression in any of the images.

> I just tried again with --disable-effects all in the spicec client and
> it did not improve the LibreOffice or PuTTY painting nor the slight
> general lagginess we notice - John

This requires the Spice guest agent to be installed, running and 
communicating over virtio-serial to work.
Y.

>
>