Hide Forgot
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.
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 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.