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

[Antoine Martin]

On 12/10/16 06:53, Mukul Agrawal wrote:
> This thread brings an interesting question to my mind :-
> 
> If I am using the HTML5 client, therefore loosing the seamless-ness and
> all individual window benefits, then in that case is there any
> fundamental difference and/or benefit of using XPRA versus noVNC and
> vice-versa? Or should we expecting them to be same/similar, at least in
> principle?
It will be more similar because of the lack of a seamless mode, but with
some added benefits:
* sound support (being refactored)
* video encoders - much faster (new client, in progress)
* support for proxy servers, etc..
etc

> I run interactive graphical application across internet with reasonably
> fast typical household internet connections (e.g. I can stream Netflix
> on couple of devices simultaneously without any issues). XPRA python
> clients generally work very well but HTML5 client does not. noVNC also
> seems to do OK job. 
The new HTML5 client code isn't ready yet, but I've been told it is as
fast as the Python client :)

Cheers
Antoine


> 
> 
>  
> Regards,
> Mukul ( https://sites.google.com/site/mukulagrawal )
> 
> 
> On Sunday, October 9, 2016 8:53 AM, Antoine Martin via shifter-users
> <shifter-users at lists.devloop.org.uk> wrote:
> 
> 
> On 07/10/16 12:28, Thomas Esposito wrote:
>> 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.
> They also have much fewer constraints: no individual windows (that come
> and go, each with its own rate of screen updates..), no video encodings,
> no sound, no sound synchronization (which delays video), etc..
> 
>> I found this interesting read...
> It is.
> 
>> https://github.com/TigerVNC/tigervnc/wiki/Latency
> There's some very good points, it looks like we have already implemented
> most of these ideas in xpra: unsolicited updates, RTT (ping), per-client
> backlog accounting, flow-control..
> 
> As per the ticket link in my previous reply, I suspect that the flow
> control is being over-optimistic and overfills the network.
> The problem is that this works really well for fast LANs and so I don't
> want to start changing those heuristics without having some reproducible
> pathological test cases to fix. Adding latency and packet loss with tc
> doesn't seem to reproduce these problems so far. But if you can find a
> setup that does, we'll make sure to fix it!
> 
> Cheers
> Antoine
> 
> 
> 
>>
>>
>> On Oct 7, 2016 12:05 AM, "Thomas Esposito" <tmesposito00 at gmail.com
> <mailto:tmesposito00 at gmail.com>
>> <mailto:tmesposito00 at gmail.com <mailto: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 <mailto:antoine at nagafix.co.uk>
> <mailto:antoine at nagafix.co.uk <mailto: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
> <http://xpra.org/trac/ticket/999><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...
>>
>>
> 
> _______________________________________________
> shifter-users mailing list
> shifter-users at lists.devloop.org.uk
> <mailto:shifter-users at lists.devloop.org.uk>
> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
> 
>