Frediano Ziglio писал 2020-06-23 18:01:
Frediano Ziglio писал 2020-05-25 10:19:Hi,
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.
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.
Hi,
I was more speaking at queue in general, but I think part of the issue
are the network buffers in this case beside client queue.
I prepare a small experimental branch at https://gitlab.freedesktop.org/fziglio/spice/-/tree/wan_experiments
if you want to try, it allows to define SPICE_DEBUG_SNDBUF and
SPICE_DEBUG_JPEG_QUALITYand https://gitlab.freedesktop.org/fziglio/spice/-/commit/ba64ca4ef02ee2aa49401f199aebff6ef6f93d63),
they should help a bit.
I tried to limit my network to 100KB/s and it was less terrible than I though,
beside an initial pretty large time to start.
Regards,
Frediano
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel