[Spice-devel] xf86-video-qxl performance

[Alon Levy]

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