[Spice-devel] Unfair comparisons with RDP

[John A. Sullivan III]

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.

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