[winswitch] high latency link issue [was: The last usable..]

[Antoine Martin]

Hi Martin,

I have moved your issue to the bug tracker here:
https://www.xpra.org/trac/ticket/153
If you can provide a little bit more of information there about your
specific application and bandwidth constraints, I am sure we can come up
with a better solution. (there is a hack/workaround in the ticket already)
As for the opengl stuff that prevented you from using trunk, I've backed
that out:
https://www.xpra.org/trac/changeset/976
So you should be able to test that again.

Cheers
Antoine



On 06/26/2012 05:41 PM, Martin Ebourne wrote:
> I am in the slightly unusual position where my day job requires me to
> run everything in New York while I live in Australia. That is everything
> I use (xterm, emacs, firefox, evolution, rdesktop, and more) runs on a
> host in NY and I work from home permanently over ADSL in Australia over
> ssh with X forwarding.
> 
> The minimum round trip (ping) time is 300ms, and since everything I do
> has to go via this it probably makes me more latency sensitive than
> most. Fortunately xpra (at least the older versions) is awesome at
> removing the round trips so I only pay the latency cost once and making
> this arrangement entirely usable.
> 
> Recently I decided to try the latest versions of xpra to get some of the
> new benefits (for the last couple of years I've been using a pre-fork
> checkout from hg) but unfortunately I found the experience to be quite
> unusable.
> 
> I first tried xpra 3.2 but the latency was terrible, multi-second waits
> were absolutely commonplace. I tried successively older versions until I
> found the last usable version of xpra which was 0.7.30.
> 
> Wanting to narrow this down some more I built some versions from svn and
> found that r283 was the last usable revision in terms of responsiveness
> (though it had some redraw issues I never had on the pre-fork version).
> Looking at r284 I found it implemented a new feature "damage_sequence"
> which was enabled in the client. By making a one line change to the
> client to disable this feature r284 itself became quite usable too. I am
> now using r513 with damage_sequence disabled, and it is still usable
> (possibly a little slower than r283 but I'm not sure as network leg
> varies). r513 hasn't had any redraw problems so far.
> 
> In r514 the damage_sequence option is removed in the server and versions
> post that are again unusable due to high latency for me. I've tried up
> to r920 with the same results. Trying the various different options for
> encoding etc did not help. The latest HEAD fails with some opengl errors
> for me.
> 
> I'd like to be able to upgrade to the latest versions. Have you any idea
> what the problem is and if there is a way to fix it?
> 
> Cheers,
> Martin
> 
> _______________________________________________
> shifter-users mailing list
> shifter-users at lists.devloop.org.uk
> http://lists.devloop.org.uk/mailman/listinfo/shifter-users