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) > > 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