[Spice-devel] Unfair comparisons with RDP

[John A. Sullivan III]

On Mon, 2011-07-04 at 21:07 +0300, Yaniv Kaul wrote:
> 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.
> 
> >
> >
> 
Hello, all.  I'll return to this thread with the general results of our
testing so far.  Alas, as much as we want it to be the opposite, RDP is
still trouncing SPICE - at least in our setup.

The agent does appear to be running and communicating over a
virtio-serial device as we can disable effects.  We are experiencing
some instability with the agent as described in another thread.

Assuming that the performance problems were related to Linux clients
perhaps not having as much of the client API implemented as Windows, I
finally broke down, wiped out one of our Asus netbooks, and restored
Windows XP from the system recovery disk.  This way I could observe and
compare performance first hand in the lab.

I tried with the downloaded binary from the SPICE download page and
compiling 0.8.1 from source (both appear to be the same).  To my great
disappointment, I had the same poor results on the Windows client with
the rudimentary but common test I've been running - opening PuTTY and
opening a document in LibreOffice.  With the latter, I literally see the
icons paint one at a time and the repaint three to four times just to
open the document.  Every mouse click is just slightly delayed

What are the next steps to determine why we are getting so much better
performance out of RDP? This isn't meant as flame bait; we sincerely
want to assist the project with our real world experiences and testing
and make SPICE the preferred remote desktop protocol.  As I hope you can
tell, we are certainly willing to put in the hours.  Thanks - John