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