[Spice-devel] Work via slow networks

[Илья]

Frediano Ziglio писал 2020-06-23 18:01:

> Frediano Ziglio писал 2020-05-25 10:19: 
> I have a problem with slow rendering of a changing desktop via a slow
> network. SPICE tries to render all the states of the screen
> sequentially, instead of immediately drawing the final state.
> 
> What settings can you remove this behavior? 
> Hi,
> I'm not sure, unfortunately, there's a way to entirely remove this
> behavior,
> at least with current optimizations.
> Can you describe better your case?
> What's slow mean, I mean, speed? 10Mbit? Less? More?
> Do you know the latency of the connection?
> What type (mobile/wifi/cabled/lan/wan) ?
> Which kind of guest (OS/configuration/use case) are you using?
> In the subject you state a "slow network" in the message you speak
> about "slow rendering", that's quite different from the way I see it,
> what specific issues are you noting?
> 
> Frediano

The channel is UDP OpenVPN via the Internet. The total load from
everything turns out to be about 100Kib. But this is not a direct
channel limitation. The channel may be larger. If you use the TCP
version of OpenVPN, then it will be displayed even more slowly. It seems
that the server is waiting for some confirmation from the client.

Client and server Ubuntu 18.04.

With a smooth fading or brightening of the Windows screen on a virtual
machine on the client, I see all the successively changing brightness.
The same thing happens when a video or something changes is drawn in the
browser.

 Hi,
  not much to recommend with these conditions. I think quite out of
SPICE
can handle.

The original design was more about sending rendering commands to clients
which does not help much with so slow bandwidth.

One of the 2 options to try is to force "wan optimization" setting it to
"always". This will use more JPEG for compression. Another would be to
reduce "jpeg_quality" setting (dcc.cpp) to a lower value (currently
fixed
to 85).

An unfortunately VPN and queueing does not help, especially if TCP.
The reason is that while the server (which mainly send data) has a fast
connection to the VPN gateway the client doesn't so the server probably
will use a large queue causing latency issues. I have a quite dirty and
experimental patch to limit the queue but it won't help with other
issues.

I think (it could be I'm wrong) that an approach more VNC like (drawing
all at host/guest level then send the collapsed changes to client) would
be better. I have another dirty patch but at the moment is even worse
at the optimization level so won't help too.

Regards,
  Frediano

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. 

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/spice-devel/attachments/20200623/34a9fb3a/attachment.htm>