Hi ----- Original Message ----- > From: Victor Toso <me@xxxxxxxxxxxxxx> > > 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@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/spice-devel > _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel