[Spice-devel] [RFC spice-gtk 0/5] Quality of Service and monitoring network usage

[Marc-André Lureau]

Hi

----- Original Message -----
> From: Victor Toso <me at victortoso.com>
> 
> Hi,
> 
> For a while now I've been playing with the overall network usage with
> spice-gtk and trying to think in a way to avoid situations where
> channels which are transferring files don't interfere too much on
> channels like display or input as they are very important to the user
> experience.
> 
> This has been proved quite difficult (tm) but hopefully this patches can
> help.
> 
> In the last patch, I'm measuring and storing the data rate for read and
> write on each channel in order to plot charts for seeing what is going
> on in regard network usage per channel.
> 
> I'm considering moving this 'saving network data' to spice-gtk so we can
> make it more usable with other clients too. Opinions?
> 
> I've saved 5 tests + images at [0] and I'll mention them in the notes
> bellow. All the tests were using Fedora 25 (client and guest) and I'm
> targeting only webdav + display channels.
> 
> [0] https://people.freedesktop.org/~victortoso/imgs/spice/qos-tests/
> 
> In the first 03 tests I'm transferring two files (second only when the
> first one is done) 200MB and 400MB in size, from the guest fs to the
> shared folder. During the whole time the stopwatch from Clocks app is
> running as it does a great job drawing several times per second :)
> 
> Streaming and image compression are off.
> 
> In tests 04-05 I'm transferring a bigger file (1.4 GB) with caution as
> it is *very easy* to run out of memory in the host and having the VM
> killed by the operation system. Bug [1] is around spice-server not
> controlling the amount of data it is storing.
> 
> [1] https://bugs.freedesktop.org/show_bug.cgi?id=100550
> 
> So, a few notes of this experience:
> 
> * I'm quite amazed by how much data the display-channel can transfer.
>   Considering client-machine = host-machine, data rate can go as big as
>   ~200 MiB/s but my feeling is that having overall bandwidth of 50 MiB/s
>   did not affect _my_ user experience in those tests.
> 
> * I can see the throttling working but I wonder if it should be
>   more/less aggressive depending on the network usage?
> 
> * A few bugs around memory usage. By default, if we have to store a file
>   in memory we should be more careful about it.
> 
> Last but not least, I wonder if we should have an option to limit
> bandwidth usage for the whole session. I think it can be easy to extend
> this patches to achieve that.
> 

My main question is about the design to place throttling on the client, why not at the server instead? We already use SO_PRIORITY for the sound channel. Have you tried doing more server-side / socket tweaking before doing client side computations that may have various issues?

thanks

> Thanks for any comments,
>     toso
> 
> PS: code in qos branch of
> https://gitlab.com/victortoso/spice-gtk/
> 
> Victor Toso (5):
>   spice-channel: new 'total-write-bytes' property
>   qos: introduce quality of service to channels
>   qos: bandwidth computation
>   qos: introduce channel priority throttling
>   spicy: save data measurements for each channel
> 
>  src/spice-channel-priv.h |   1 +
>  src/spice-channel.c      |  51 ++++++
>  src/spice-option.c       |   5 +
>  src/spice-session-priv.h |   5 +
>  src/spice-session.c      | 469
>  ++++++++++++++++++++++++++++++++++++++++++++++-
>  tools/spicy-gnuplot.sh   |  19 ++
>  tools/spicy.c            | 259 +++++++++++++++++++++++++-
>  7 files changed, 807 insertions(+), 2 deletions(-)
>  create mode 100755 tools/spicy-gnuplot.sh
> 
> --
> 2.9.3
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/spice-devel
>