Created attachment 813386 [details] vnc-fast-spice-slow-comparision.ogv I installed Fedora 20 Beta TC4 in qemu, using: ionice -c 3 qemu-kvm -enable-kvm -global qxl.ram_size=1x1024 -m 2048M -smp 4 -drive file=./Fedora-20-Beta-TC4-x86_64-netinst.iso.qcow2,index=0,media=disk,cache=unsafe -localtime -serial file:/tmp/qemu-Fedora-20-Beta-TC4-x86_64-netinst.iso.qcow2-output.log -name Fedora-20-Beta-TC4-x86_64-netinst.iso.qcow2 -cdrom /local/mfabian/iso/Fedora-20-Beta-TC4/Fedora-20-Beta-TC4-x86_64-netinst.iso -boot c -spice port=6000,disable-ticketing -vga qxl -display vnc=:4 -net nic -net user,hostname=Fedora-20-Beta-TC4-x86_64-netinst.iso.qcow2,hostfwd=tcp::5556-:22 -monitor stdio -usb QEMU 1.6.1 monitor - type 'help' for more information (qemu) Then I watch the guest with spice protocol using remote-viewer spice://localhost:6000 and vnc protocol using: vncviewer :4 (I could also use “remote-viewer vnc://localhost:5904”, this makes no difference as far as this bug report is concerned, it is also fast). Updating the graphics often seems *much* slower when using spice compared to vnc. This is especially easy to notice when scrolling in firefox on a page which has many pictures. The attached video shows “vncviewer :4” on the left side and “remote-viewer spice://localhost:6000” on the right side, both looking at the same guest. In the video, I scroll down in the web page shown by firefox, one can see that the graphics update is quite fast in the left window using vnc but very slow in the right window, using spice.
Could this be a potential beta blocker?
Seems both slow and with some nasty artifacting. But what beta or final release criteria is violated by this?
Seems better with a F20 host. Now I am wondering if this is more of F19 host vm issue? F20 Beta Desktop guests also seem to perform better with 1.5GB ram.
Discussed at 2013-11-13 blocker review meeting - http://meetbot.fedoraproject.org/fedora-blocker-review/2013-11-13/f20-final-blocker-review-1.2013-11-13-17.01.log.txt . Rejected as a blocker: slowness in KVMs is inconvenient but not release blocking, and those at the meeting are not seeing this exact problem.
please check with the latest xorg-x11-drv-qxl driver that is queued for f20.
It's not just scrolling in Firefox that's affected by this, I've seen similar sluggishness and horizontal 'stripes' of the display lagging behind the rest during refreshes in other apps too (e.g. gnome-initial-setup). And I can reproduce the same behaviour with an F19 guest (install from F19 live image, so the F19 package set as of release time) on an F20 host, interestingly, but I'm pretty sure it wasn't happening with F19-on-F19 during F19 validation time. Yet Mike reports seeing it with an F20 guest on an F19 host...
Adjusting the summary, this seems like a more general issue: for me, graphical performance in 20-on-20 GNOME VMs is just very very sluggish, I have the scrolling problem the OP mentions but that's not all. I can actually see what look like JPEG compression artefacts in my clients just performing normal operations like opening a terminal and typing stuff. It's kind of odd.
proposing as a final FE at least, it's kind of painful testing live images with this slowness.
To reproduce - at least my version - you just need to have an F20 host, boot an F20 desktop live image on it, and try using it. Just open a browser and browse around or open a terminal and run some stuff, move a few windows, normal stuff. The very sluggish performance is pretty immediately apparent. A test I just did was to open two gnome-terminal windows, run top in one, and drag the other one around while watching the numbers in the other. There's very obvious artifacting on the drag operation - whole sections of the window don't move - and gnome-shell's CPU usage in top quickly jumps way over 100%. I'll have to compare and see if similar bad behaviour exists in KDE...
OK, it seems to behave pretty well in KDE. Mike, can you confirm this only affects GNOME for you? If so it looks like we're looking at a sudden extreme drop in llvmpipe-on-qxl performance, or something similar.
Hmmm. I can reproduce the poor performance in an F19 (release-time) guest on an F19 (fully updated) host (and an F19 release-time guest on an F20 host, for that matter). But I'm almost sure it wasn't behaving like this at F19 release time. Do you recall whether you saw it back then, Mike? I wonder if something that's been pushed to F19 stable, not just F20, since F19 release is to blame, here.
18-on-20 is definitely different. A lot less artifacting. It's still not exactly perfect - if you do the drag-a-terminal-window-around test, it lags appreciably behind the cursor - but there isn't bad artifacting in that test, or in a Firefox scroll-a-pictureful-webpage test, and I never see the 'heavily overcompressed JPEG-alike' artifacting in an F18 guest.
Bug 1019020 may be a duplicate.
airlied suggested that I disable Spice streaming mode: <graphics type='spice' autoport='yes'> <streaming mode='off'/> </graphics> in the VM definition. That does indeed make things a huge amount better in all respects. Faster, no artifacting that I can catch, observed CPU usage in the guest when doing the terminal window drag test is much lower.
xorg-x11-drv-qxl-0.1.1-3.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/xorg-x11-drv-qxl-0.1.1-3.fc20
The update improves things massively for me, about as good as disabling streaming.
+1 FE.
+1 to FE from me. having sluggish guests seems not nice
acceptedfreezeexception with three votes, thanks.
Package xorg-x11-drv-qxl-0.1.1-3.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing xorg-x11-drv-qxl-0.1.1-3.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-22263/xorg-x11-drv-qxl-0.1.1-3.fc20 then log in and leave karma (feedback).
xorg-x11-drv-qxl-0.1.1-3.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 1019020 has been marked as a duplicate of this bug. ***
I'm re-opening this and re-setting version to 19 as I think we ought to ship the workaround as an update to F19 as well - per my testing (see c#6), it affects F19 guests too.
xorg-x11-drv-qxl-0.1.1-3.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/xorg-x11-drv-qxl-0.1.1-3.fc19
Package xorg-x11-drv-qxl-0.1.1-3.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing xorg-x11-drv-qxl-0.1.1-3.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-23510/xorg-x11-drv-qxl-0.1.1-3.fc19 then log in and leave karma (feedback).
xorg-x11-drv-qxl-0.1.1-3.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.