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