[Spice-devel] xf86-video-qxl performance

[Alon Levy]

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 at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/spice-devel
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel