[Spice-devel] spice multiclients issue

[Rozen Lin]

Hi, Alon & spice-dev guys,
  Thanks for your replies and help, now let me conclude the issues we've
faced during the use of multi-clients:
0. Test env.: 
1) host: Ubuntu10.04 server x64. 
   VM: Windows XP with spice-guest tools installed.
2) spice-server-0.12 + qemu-kvm-1.2
3) spice-client-0.12 for X11, aka, spicec.
4) 2 client machines: both Ubuntu10.04 server x64, one connects to host
thru wired LAN network, the other is thru wireless.

1. the assert/crash on ring_item/cursor_item:
1) assert in red_worker.c:free_one_drawable()
>   spice_assert(ring_item);
repro steps: the two clients above connect to the host at the same time
and play video in VM for a while, the spice server will assert.
2) crash in red_worker.c:get_cursor_item()
: condition `!(cursor_item = alloc_cursor_item(worker))' reached
repro steps: the two clients above connect to the host at the same time
and play video in VM for a while then pause for a moment and continue
again, the spice server will give that warning and crash.

our hotfix for this is just make sure the drawables/cursors will never
run out by 
alloc_drawable():
 1615     // the buffer is exhausted, realloc for more
 1616     /*
 1617     if(!worker->free_drawables)
 1618     { // malloc() for more...

but check the red_worker.c, it already has the mechanism to handle the
runout by ,e.g, free_one_drawable(), what we are still unclear yet is
that why it fails for this, perhaps this is a bug in the ring.h?

2. poor network jammed the client.
   tested in the same env. as 1. with hotfix patched, spice server will
not crash anymore but 
1) after playing DVD video in VM for about 20 mins, the wireless(or
other network which has effective network traffic <10M/s) client will be
jammed in display and has long delay(>10s) to the input events , yet
meanwhile another client thru wired network works well and fast in
input/display.
2) we know this problem is inevitable in poor network, but the point is
we can accept the frame losing rather rather the display/input lag which
will cause the async use experience among the multiclients. Any
suggestion to achieve the sync even in such network env? 

3. the image/stream compress rate.
 to solve 2, we try to change the compress rates for image/stream
according to the calculation of the diff network speed of diff clients,
any better solution for this?
  
  Any clue and suggestion is much appreciated, thanks in advance!
  Best regards,
       Rozen.


>That assert happens whenever the preallocated list of drawables runs
>out of drawables.
>So it's a network latency and guest activity issue. 
>The experimental status is more of a "the code is there, it might work for some durations, but don't rely on it" because of this issue. 
>I don't know why it works with some clients better for you, I can only assume that the clients are contributing/changing the latency 
>somehow to create a larger pipe (and as a result smaller free drawable list, until exhaustion) for some clients and not others.
>I really wish to get back to this and finish it properly, since I think this is a very useful feature.