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