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

[Marc-André Lureau]

Hi

----- Original Message -----
> Hi,
> 
> On Fri, Apr 07, 2017 at 09:31:57AM -0400, Marc-André Lureau wrote:
> > > [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.
> 
> To be honest, I did not think about having the solution in the server
> side. Considering that the server does the ping and measures bandwidth
> it makes sense (although ping is only in one channel and bandiwidth test
> is done only once at the moment).
> 
> > Have you tried doing more server-side / socket tweaking before doing
> > client side computations that may have various issues?
> 
> Not really. Is there a way to have good control of network usage by
> tweaking sockets?
> 
> Still, why not a client side solution (even if done in a different way).

I think there is much more flexibility to do qos in various ways on the side that produces the data. In general, the spice client is rather "passive", it consumes the data it is being sent and doesn't have much control over it (unlike streaming technologies that are adaptive and pull data themself). When the client has to send data, we can simplify the policy like this imho: input > audio recording > data transfer (file/dnd etc). I don't know much about SO_PRIORITY and if there are equivalent for Windows, or other alternatives, but I would try using it on the sending sockets client&server. If it's satisfying enough, it sounds easier to maintain and to configure. Give it a try! :)


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