<html><body><div style="font-family: courier new,courier,monaco,monospace,sans-serif; font-size: 12pt; color: #000000"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;" data-mce-style="border-left: 2px solid #1010FF; margin-left: 5px; padding-left: 5px; color: #000; font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div><br></div><p>Frediano Ziglio писал 2020-06-23 18:01:</p><blockquote style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0" data-mce-style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0;"><div class="pre" style="margin: 0; padding: 0; font-family: monospace" data-mce-style="margin: 0; padding: 0; font-family: monospace;"><blockquote style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0" data-mce-style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0;">Frediano Ziglio писал 2020-05-25 10:19:<blockquote style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0" data-mce-style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0;"><blockquote style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0" data-mce-style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0;"><br> I have a problem with slow rendering of a changing desktop via a slow<br> network. SPICE tries to render all the states of the screen<br> sequentially, instead of immediately drawing the final state.<br> <br> What settings can you remove this behavior?</blockquote><br> Hi,<br> I'm not sure, unfortunately, there's a way to entirely remove this<br> behavior,<br> at least with current optimizations.<br> Can you describe better your case?<br> What's slow mean, I mean, speed? 10Mbit? Less? More?<br> Do you know the latency of the connection?<br> What type (mobile/wifi/cabled/lan/wan) ?<br> Which kind of guest (OS/configuration/use case) are you using?<br> In the subject you state a "slow network" in the message you speak<br> about "slow rendering", that's quite different from the way I see it,<br> what specific issues are you noting?<br> <br> Frediano</blockquote><br> The channel is UDP OpenVPN via the Internet. The total load from<br> everything turns out to be about 100Kib. But this is not a direct<br> channel limitation. The channel may be larger. If you use the TCP<br> version of OpenVPN, then it will be displayed even more slowly. It seems<br> that the server is waiting for some confirmation from the client.<br> <br> Client and server Ubuntu 18.04.<br> <br> With a smooth fading or brightening of the Windows screen on a virtual<br> machine on the client, I see all the successively changing brightness.<br> The same thing happens when a video or something changes is drawn in the<br> browser.<br> <br></blockquote>Hi,<br> not much to recommend with these conditions. I think quite out of SPICE<br> can handle.<br> <br> The original design was more about sending rendering commands to clients<br> which does not help much with so slow bandwidth.<br> <br> One of the 2 options to try is to force "wan optimization" setting it to<br> "always". This will use more JPEG for compression. Another would be to<br> reduce "jpeg_quality" setting (dcc.cpp) to a lower value (currently fixed<br> to 85).<br> <br> An unfortunately VPN and queueing does not help, especially if TCP.<br> The reason is that while the server (which mainly send data) has a fast<br> connection to the VPN gateway the client doesn't so the server probably<br> will use a large queue causing latency issues. I have a quite dirty and<br> experimental patch to limit the queue but it won't help with other issues.<br> <br> I think (it could be I'm wrong) that an approach more VNC like (drawing<br> all at host/guest level then send the collapsed changes to client) would<br> be better. I have another dirty patch but at the moment is even worse<br> at the optimization level so won't help too.<br> <br> Regards,<br> Frediano<br> <br></div></blockquote><p> </p><p>Indeed, the VSC works better under such conditions. But unfortunately it doesn’t have some very convenient functions, for example, auto-adjustment of the server size for the client.</p><p>As I understand from your letter, sending data for rendering occurs through the queue. As an idea, I can offer to combine packages for rendering if they have not had time to leave yet. Or monitor the queue overflow and, in case of overflow, clear it and send the entire screen in one packet. This will give the desired effect for channels with minimal performance.</p><div> </div></blockquote><div>Hi,<br></div><div> I was more speaking at queue in general, but I think part of the issue<br></div><div>are the network buffers in this case beside client queue.<br></div><div><br></div><div>I prepare a small experimental branch at <a href="https://gitlab.freedesktop.org/fziglio/spice/-/tree/wan_experiments">https://gitlab.freedesktop.org/fziglio/spice/-/tree/wan_experiments</a><br></div><div>if you want to try, it allows to define SPICE_DEBUG_SNDBUF and <code>SPICE_DEBUG_JPEG_QUALITY</code><br></div><div>(see <a href="https://gitlab.freedesktop.org/fziglio/spice/-/commit/2d3939a424284e44203bd5ed25cd37dbb9e66623">https://gitlab.freedesktop.org/fziglio/spice/-/commit/2d3939a424284e44203bd5ed25cd37dbb9e66623</a><br></div><div>and <a href="https://gitlab.freedesktop.org/fziglio/spice/-/commit/ba64ca4ef02ee2aa49401f199aebff6ef6f93d63">https://gitlab.freedesktop.org/fziglio/spice/-/commit/ba64ca4ef02ee2aa49401f199aebff6ef6f93d63</a>),<br></div><div>they should help a bit.<br></div><div><br></div><div>I tried to limit my network to 100KB/s and it was less terrible than I though,<br></div><div>beside an initial pretty large time to start.<br></div><div><br></div><div>Regards,<br></div><div> Frediano<br></div><div><br></div></div></body></html>