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):
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
Steps to Reproduce:
1. Install a RHEL guest in a RHEV 3.0 environment
2. Install an app like eclipse and use it
Very slow responses for the application to come up and move between objects in the app.
Attached the network trace of the communication and the qemu log for the RHEL guest.
Created attachment 523225 [details]
qemu log file for the guest
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
There were many DRAW_FILL commands, so we may want to look at optimizing
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