[winswitch] high latency (was dpi switch..)

Thomas Esposito tmesposito00 at gmail.com
Fri Oct 7 06:28:48 BST 2016

I've been thinking a bit more...

Isn't the problem of avoiding the creation of a backlog of window updates
that add to latency something that VNC has to solve as well? They seem to
be doing a decent job of it.

I found this interesting read...


On Oct 7, 2016 12:05 AM, "Thomas Esposito" <tmesposito00 at gmail.com> wrote:

> As an experiment, I tried binding my xpra session to TCP port 5910, which
> is within the range typically used by VNC (also no encryption, which is
> fine because I'm on a private corporate intranet). The idea is to test out
> a theory that the network admins have prioritized VNC traffic (because
> there are a lot of people depending on remote VNC access) by classifying on
> the TCP port.
> It could be placebo, but it actually seems much better. I don't really see
> the latency spikes that I was seeing before, although I'd have to use it
> longer to be sure. It could also simply be that there is less network
> traffic at this time of day. IF my theory is true, and VNC traffic
> (identified by port) is being treated more favorably and consistently in
> the network, perhaps this is reducing the probability that I will encounter
> xpra bugs manifesting as catastrophic performance degradation triggered by
> changing network conditions.
> On Thu, Oct 6, 2016 at 12:06 AM, Antoine Martin <antoine at nagafix.co.uk>
> wrote:
>> On 06/10/16 09:20, Thomas Esposito wrote:
>> > Just to add a bit more info...
>> >
>> > I've tried x264, lz4, and png (32, 8, and gray scale) encodings and none
>> > of these approach the responsiveness and perceived performance of
>> > TigerVNC with Tight encoding.
>> >
>> > When I look at the stats and graphs under session info, I see lots of
>> > latency spikes, particularly under Damage latency, which spikes into
>> > several seconds.
>> That would be a bug. Although xpra has been heavily optimized for fast
>> networks, with relatively low latency and low packet loss, it should
>> still adapt to more challenging network conditions.
>> Others have reported this before but I've never seen it for myself
>> directly, which makes it hard to fix. Could be the same as:
>> http://xpra.org/trac/ticket/999
>> Please add your information there.
>> > I've also tried this on a Microsoft Azure Ubuntu VM that I've been
>> > playing around with via a free trial account. The performance seems
>> > better (same encodings), but occasionally gets pretty bad. Maybe it's
>> > just intermittent network issues.
>> Sounds like it.
>> Cheers
>> Antoine
>> > I haven't been able to get VNC working
>> > on this VM...

More information about the shifter-users mailing list