Hi, On Mon, 2016-01-25 at 06:48 -0500, Frediano Ziglio wrote: > > > Hi Frediano, > > On Čt, 2016-01-14 at 12:52 -0500, Frediano Ziglio wrote: > > > > On Thu, 2016-01-14 at 12:07 -0500, Frediano Ziglio wrote: > > > > > > > > On Thu, Jan 14, 2016 at 10:27:02AM -0500, Frediano Ziglio > wrote: > > > > > Had a small discussion with Pavel. > > > > > We agree that original code is quite complicated and is hard > to > > > > > understand > > > > > the final compression format used. > > > > > > > > > > So we would like to have some public discussion about the > topic. > > > > > > > > > > I personally agree we should have a single code deciding the > > > > > compression > > > > > to use. > > > > > > > > I definitely agree here. For one, having different compression > being > > > > used depending on whether the qxl driver is used or not is > unexpected > > > > (eg if you set image compression to glz, lz will still be used > during > > > > initial bootup, and then will 'switch' to glz later on. I > haven't looked > > > > at the code, so there might be good reasons for that). > > > > > > > > > > > > > > This is the list of actual compressions: > > > > > - AUTO_GLZ; > > > > > - AUTO_LZ; > > > > > - QUIC; > > > > > - GLZ; > > > > > - LZ; > > > > > - LZ4. > > > > > A client can also decide to disable compression. > > > > > > > > > > The AUTO_XXX looks like they should use QUIC as a fallback if > XXX is > > > > > not > > > > > possible or if an image with high graduality is detected. > > > > > > > > (side question, do we have numbers on compression ratio and cpu > usage > > > > for quic/lz/glz/lz4?) > > > > > > > > > > Brief and raw of a Windows replay capture > > > > > > Images MB before MB after Ratio CPU time > > > LZ4 193 24.21 2.43 10.04% 0.04 > > > QUIC 204 23.11 1.66 7.18% 0.44 > > > GLZ 190 20.05 1.2 5.99% 0.14 > > > LZ 202 20.42 2.04 9.99% 0.15 > > > > > > So why use Quic ? > > > > Interesting data. Indeed, QUIC seems to be the worst choice. from > this data, > > it > > seems that you'd want GLZ if you were optimizing for network > bandwidth, and > > LZ4 > > if you're optimizing for CPU usage. Might be nice to see data for a > slightly > > larger sample as well. > > > > Out of curiosity, did you write a little utility for doing this > benchmark, or > > did you just modify the code in-place?? Having a little benchmark > utility > > that > > you could run on different replay captures might be a useful thing > to have in > > the repository... > > > > Jonathon > > > > > > No code modification at all. Compile with COMPRESS_STAT enabled, run > replay > utility with SPICE_DEBUG_LEVEL=3 set at the end you see a similar > table > (I added just ratio with LibreOffice calc). > Oh... you just need to use -C replay option with > - 4 quic > - 5 glz > - 6 lz > - 7 lz4 > (not sure about 5/6, maybe swapped). > > would you mind running with no compression so that we can get CPU > baseline? FWIW I've put inverted numbers to a chart (1/cpu time, > orig_size/compressed_size, so that greater number is better) and the > result is here: > > You can imagine the numbers as a number of VMs you can squeeze into a > single host given a cpu/network constraint. > > Good graph. > > I discovered in the meantime that I was running my test with -O0 (so > no optimization) so turned out these > data are completely wrong (lz4 is coded in a different library so not > affected by -O setting). I collected some more data (i did not count uncompressed images) and run it with -O2 and it seems that glz is always better. But as Frediano said it would be nice to have a recording of a daily usage [0] and summarize it. Pavel [0] http://www.spice-space.org/docs/manual/#_recording_replaying_spice_ server_traffic > > I was wondering, if the current code is indeed messy if it couldn't be > replaced with an adaptive algorithm e.g. starting with some "middle ground" > algorithm (LZ4 looks like the candidate) and move up if server detects packet > loss or move right if server can't compress images fast enough...>
> I think would be really helpful to collect different replay captures of > normal day job. > > > IIRC VDI benchmark could be the tool to get such a capture.> > > David > > Frediano > > _______________________________________________ > Spice-devel mailing list > [email protected]> http://lists.freedesktop.org/mailman/listinfo/spice-devel>
_______________________________________________ Spice-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/spice-devel
