Bug 738416 - Spice sessions on RHEL guests - very slow
Summary: Spice sessions on RHEL guests - very slow
Keywords:
Status: CLOSED DUPLICATE of bug 710385
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: xorg-x11-drv-qxl
Version: 6.1
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Søren Sandmann Pedersen
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks: 731146
TreeView+ depends on / blocked
 
Reported: 2011-09-14 18:14 UTC by Anitha Udgiri
Modified: 2018-11-28 21:10 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-02-28 14:21:51 UTC


Attachments (Terms of Use)
This is the network trace using wireshark of the communication happening between the client and the guest. (14.63 MB, application/octet-stream)
2011-09-14 18:14 UTC, Anitha Udgiri
no flags Details
qemu log file for the guest (59.48 KB, application/octet-stream)
2011-09-14 18:15 UTC, Anitha Udgiri
no flags Details

Description Anitha Udgiri 2011-09-14 18:14:23 UTC
Created attachment 523223 [details]
This is the network trace using wireshark of the communication happening between the client and the guest.

Description of problem:
Working with applications on RHEL 6.1 guests results in very slow and annoying speeds for screen responses.
The responses are almost double the time taken when tested with VNC.

Version-Release number of selected component (if applicable):
RHEV3.0 beta1
RHEL 6.1 with xorg-x11-drv-qxl-0.0.12-9.el6.x86_64 and spice-vdagent-0.6.3-8.el6.x86_64 

How reproducible:
Always

Steps to Reproduce:
1. Install a RHEL guest in a RHEV 3.0 environment
2. Install an app like eclipse and use it
3.
  
Actual results:
Very slow responses for the application to come up and move between objects in the app.

Expected results:


Additional info:
Attached the network trace of the communication and the qemu log for the RHEL guest.

Comment 1 Anitha Udgiri 2011-09-14 18:15:28 UTC
Created attachment 523225 [details]
qemu log file for the guest

Comment 2 Anitha Udgiri 2011-09-14 18:17:01 UTC
Initial analysis by Yaniv Kaul :

The initial image (a 1280x768, 32bit image) arrived QUIC compressed (not
the best compression we have), via 521 TCP segments, 22.39 seconds after
the initial connection. Size - 753,888 bytes (packet 1599, for reference).

The next image had a very similar characteristics - QUIC, 522 segments.
It arrived at 22.71 - which is strange, taking so little time since the
previous image. Anyway, also a 1280x768 image, 753,888 bytes.

Later on (packet 3199) we got a LZ_RGB image, and later on (packet 3201)
a small Jpeg image (48x48  -1124 bytes - was it worth Jpeg compressing
it?) and a zlib over glz (54x20, 214 bytes compressed, 231 uncompressed).

Packet 3205 is interesting: DRAW_COPY, SURFACE_CREATE, DRAW_FILL,
DRAW_COPY, SURFACE_CREATE, DRAW_FILL, DRAW_COPY, SURFACE_CREATE,
DRAW_FILL, SURFACE_DESTROY, SURFACE_CREATE, DRAW_COPY, SURFACE_DESTROY,
SURFACE_CREATE, DRAW_COPY, SURFACE_DESTROY, SURFACE_CREATE, DRAW_COPY,
SURFACE_DESTROY, SURFACE_CREATE, DRAW_COPY, SURCFACE_DESTROY,
SURFACE_CREATE, DRAW_COPY - where the images, if any, are 1x1 or 2x2.
Something not very efficient here (and we've seen it in the past I
think). Sending and processing so many commands may probably an issue as
well.

There were many DRAW_FILL commands, so we may want to look at optimizing
those.

There were some interesting inefficiencies there - we are sending an
image in a DRAW_COPY command - the compressed image is taking 19 bytes
(and could clearly be better compressed using a simple RLE compression)
- but it's in a 130 bytes sized message, only to be followed by another
image - 22 bytes in a 133 bytes message.

** In any case, none of the images were ever taken from the cache **


Lastly, keep in mind that you have not really tested it in a WAN
conditions - you had 1514 bytes packets. In a real WAN, you'd get less.
1300-1400, which would have made things worse.
I also doubt this capture is from a 150ms delayed pipe. Doesn't look
like it.


Note You need to log in before you can comment on or make changes to this bug.