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 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 Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel