Bug 738416
| Summary: | Spice sessions on RHEL guests - very slow | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Anitha Udgiri <audgiri> | ||||||
| Component: | xorg-x11-drv-qxl | Assignee: | Søren Sandmann Pedersen <sandmann> | ||||||
| Status: | CLOSED DUPLICATE | QA Contact: | Desktop QE <desktop-qa-list> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | high | ||||||||
| Version: | 6.1 | CC: | acathrow, cfergeau, dblechte, kem, mkenneth, mkrcmari, pmcdonou, sandmann, syeghiay | ||||||
| Target Milestone: | rc | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2012-02-28 14:21:51 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 731146 | ||||||||
| Attachments: |
|
||||||||
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. |
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.