[Spice-devel] xf86-video-qxl performance

[Alon Levy]

On Mon, May 28, 2012 at 11:29:23AM +0200, Attila Sukosd wrote:
> Low latency (and relatively low bandwidth) video streaming can be done with
> x264 and xvid (low enough for a 3d game to be playable over the net)
> However, it introduces licensing issues and high-ish CPU usage on the host
> side :(

The later is fixable with hw based compression.

> 
> 
> On Mon, May 28, 2012 at 11:19 AM, Alon Levy <alevy at redhat.com> 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)
> >
> > >
> > > 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
> >

> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel