[Spice-devel] xf86-video-qxl performance

[Attila Sukosd]

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 :(


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/spice-devel/attachments/20120528/faaaf091/attachment.htm>