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

[Mukul Agrawal]

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?

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.  

 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>> 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>> 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>
>        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
http://lists.devloop.org.uk/mailman/listinfo/shifter-users