[Spice-devel] xf86-video-qxl performance

[Yonit Halperin]

Hi,
On 05/24/2012 05:30 PM, Jeremy White wrote:
>> No, what we do is combine some operations (change/drop) by looking at
>> current outstanding messages (queued but not yet sent - in the pipe)
>> whenever we read a new message from the device (from the ring). There is
>> a good visual iirc on spice-space.org .
>
> I didn't find a visual that address that specifically; although
> the spice for newbies does have a lot of information which I haven't
> fully digested yet.
>
> I do think I have the beginning of a thread to understand the specific
> bug I'm seeing.  I see on the client that I get 500 or so draw fill
> operations each time I move the mouse over a menu choice.  If we require
> an ack every 20, at a WAN price of 80 ms per ack, you very rapidly go
> right down the tubes.  So figuring out why those draw fill operations
> didn't get condensed seems like the right place to start.

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,
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.

Hope this helps,
Yonit.

>
> Am I on the right track in looking at red_current_add in red_worker.c?
> And it looks like turning on PIPE_DEBUG may well get me a whole lot more
> info - I'll start with that.  Any other tips or clues are appreciated.
>
> Cheers,
>
> Jeremy
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel