On Mon, May 28, 2012 at 12:19:57PM +0300, Alon Levy wrote: > On Thu, May 24, 2012 at 01:24:05PM -0500, Jeremy White wrote: > > > Actually, for WAN, we require ACK for 40 messages, but we allow sending > > > up to 80, without getting an ack for the first 40. > > > From my experience with Windows guest, it sounds like the DRAW_FILL > > > commands might be related to anti aliasing, and maybe the future RENDER > > > support that Alon mentioned will indeed help with this. Meanwhile I > > > would also try to disable off-screen surfaces, as was also mentioned in > > > a previous reply, > > > > Ah, yes, sorry; I knew 20 was imprecise. But (500 / 80) * 80 ms is > > still a good bit of delay. > > > > Increasing the ack window (and pipe size) by a factor of 10 makes the > > first apparent problem vanish. > > > > Disabling off screen surfaces has the same user visible effect. > > > > Note, though, that I have the luxury of focusing on a long term agenda, > > so I'd rather pursue the 'best' solution (at least for now). > > > > > > > What OS your client has? When spice-server identifies WAN, it > > > automatically turn on Nagle's for the display channel (turns off > > > TCP_NODELAY), which should aggregate small tcp messages. However, it has > > > bad interaction with the delayed acks on the client side (especially in > > > Windows clients, where the default delayed ack timeout is 200ms iirc), > > > and overall it can lead to bigger latency between operations. We are > > > planning to get read of this, and aggregate the messages on the > > > application layer instead. > > > > I'm currently testing with Debian testing, although our eventual > > deployment platform will be a heavily modified RHEL 6 system. The > > pointer to TCP_NODELAY is also a good one; I'll play with that and see > > what effect it has. > > > > > Just to clarify, we currently don't condense messages in spice-server, > > > though it is another item in our TODO. > > > > Ah, okay, that's helpful (although there is some very limited pruning in > > red_worker.c, no?) > > > > Is that todo on anyone’s immediate radar? I'm certainly not qualified, > > but it seems like that could have an major impact on what we're trying > > to achieve (regular Office applications hosted on a pure Linux server > > across a WAN). So perhaps I need to become qualified :-/. > > I have a patchset that didn't seem to do anything so I let it go, but if > you'd like I can find it (that's the hard part) and put it somewhere you > can have a look. It aggregates packets at the application layer > (server/red_channel.c) Actually it seems it's harder to rebase it then I thought. The old branches I have are useless, I've pushed them to git://people.freedesktop.org/~alon/spice , branches old/aggregate-* > > > > > Cheers, > > > > Jeremy > > _______________________________________________ > > Spice-devel mailing list > > Spice-devel@xxxxxxxxxxxxxxxxxxxxx > > http://lists.freedesktop.org/mailman/listinfo/spice-devel > _______________________________________________ > Spice-devel mailing list > Spice-devel@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/spice-devel _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel