[Spice-devel] Work via slow networks

[Frediano Ziglio]

> 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