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