Initially filed as 

 Shaolong Hu 2013-11-29 02:53:02 EST

Description of problem:
-------------------------
Connect guest with spice under poor network speed, guest running slow.


Version-Release number of selected component (if applicable):
--------------------------------------------------------------
qemu-kvm-1.5.3-19.el7.x86_64



How reproducible:
------------------
100%


Steps to Reproduce:
--------------------
1. boot guest with qxl and spice connection

2. connect guest on another host which has poor network speed to the host running the guest (suggest using wireless or vpn to reproduce).

3. reboot guest, booting log shows up one line by one line, comparing to vnc, booting log shows up tens of lines by tens of lines (for poor speed, when next frame refreshes, tens of lines have been generated, this is understandable, but with spice, it looks like guest runs really slow rather than only displaying, it takes far more time with spice to boot up)

4. run dmesg in guest, the situation is the same with step 3, with spice, the dmesg message shows up one line by one line, it takes very long time to display all log.


Expected results:
-------------------
spice should behavior like vnc when network is poor. 


Additional info:
------------------
both guest and host are in level 3 during testing.

Comment 3 Marc-Andre Lureau 2014-07-06 17:46:25 EDT

this is due to spice server design, which will "slow" rendering for the client connection to get all relevant drawing operations. imho, this is a bad design and it should be improved. However, given that it was done like this by design, it is not a bug and should be an like "RFE: do not slow rendering & guest if client is slow"

Comment 8 David Jaša 2015-03-20 11:08:49 EDT

Marc-André, just wondering, wouldn't help a switch to server-side rendering (analogous to --deferred-fps of Xspice) help in this case?

Comment 9 Marc-Andre Lureau 2015-03-20 11:23:10 EDT

(In reply to David Jaša from comment #8)
> Marc-André, just wondering, wouldn't help a switch to server-side rendering
> (analogous to --deferred-fps of Xspice) help in this case?

There is already server-side rendering anyway. But that's not enough, it's the way drawing commands are piped directly to the client that needs to be changed. That could also help with "out of memory" bugs (garbage-collect all commands, even the one queued for the client).

Comment 10 Marc-Andre Lureau 2015-04-21 19:52:45 EDT

unlikely to happen in 7.2, it must first land upstream. imho, we should consider moving the bug there.