Re: Adaptive compression choice? [was: Re: [PATCH spice 1/3] dcc_compress_image: Handle NULL drawable]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]     [Monitors]