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 > <[email protected]> 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" <[email protected] > <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>> 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 >> <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>> 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 > [email protected] > <mailto:[email protected]> > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > _______________________________________________ shifter-users mailing list [email protected] http://lists.devloop.org.uk/mailman/listinfo/shifter-users
