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 :( <div class="gmail_quote">On Mon, May 28, 2012 at 11:19 AM, Alon Levy <<a href="mailto:alevy@redhat.com" target="_blank">alevy@redhat.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="HOEnZb"><div class="h5">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 :-/. </div></div>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) <div class="HOEnZb"><div class="h5"> > > Cheers, > > Jeremy > _______________________________________________ > Spice-devel mailing list > <a href="mailto:Spice-devel@lists.freedesktop.org">Spice-devel@lists.freedesktop.org</a> > <a href="http://lists.freedesktop.org/mailman/listinfo/spice-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/spice-devel</a> _______________________________________________ Spice-devel mailing list <a href="mailto:Spice-devel@lists.freedesktop.org">Spice-devel@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/spice-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/spice-devel</a> </div></div></blockquote></div>