[Spice-devel] [RFC] Spice channels compression

[Snir Sheriber]

Hi,


On 03/06/2017 09:05 PM, Frediano Ziglio wrote:
>> Hi,
>>
>> Thanks all for your comments
>>
>>
>> On 03/03/2017 12:49 PM, Frediano Ziglio wrote:
>>>> Hey,
>>>>
>>>> Do you have any measurements of how much bandwidth is saved on each
>>>> channel type on basic usage of linux/windows guests? Ideally, with
>>>> numbers about additional CPU usage and added latency?
>>>>
>>>> Christophe
>>>>
>>> Yes, without numbers it's a bit hard understand if worst or not.
>> The core channels i aimed to were usbredir,webdav and main, i haven't
>> came across yet with significant results in other channels.
>> The avg latency is about 0.2-0.3 ms per packet when large packet are being
>> transferred (tested on usbredir), btw i didn't try anything with windows
>> guest yet,
>> might be interesting
>>
>> Numbers are pretty dependent on what the user is doing, for example:
>> ( Number are the compression rate = uncompressed_size/compressed_size)
>>
>> 1. usbredir: connecting usb-4GB storage device with ext4 (no files transfer)
>> server -> client:
>> 2.6
>> client -> server:
>> 8.2 (4MB)
>>
>> 2.webdav : copy compressed JPEG client-> server
>> server -> client:
>> 1.27
>> client -> server:
>> 1.7 (copy jpg)
>>
> This is quite surprising. jpg should not compress that much (if not at all)
> so the 0.7 is expected to came from other data. Seems massive, even
> considering that on the reverse direction there's only a 1.27.
> This suggests that maybe Christophe hit a good point with its LEB128
> suggestion.

you are right, it started from the beginning of the stream, i guess the 
ratio
would decrease if i'll try larger compressed file this

>> 3. main : It start with impressive compression but afterwards it mostly
>> depends on user behavior , for example copy\paste of text should be
>> compressed massively in main channel
>> server -> client:
>> 150.1?! (but just for the first msgs)
> Yes, we try to detect the bandwidth sending a bit all zeroes packet :)
>
>> client -> server:
>> 2.9
>>
>> 4. cursor channel behaves similarly- large compression during boot
>> (using client
>> mouse after boot) and that's it
>>
>> in other words i would describe compression rate for these channels as:
>> Usbredir- mostly device dependent, could achieved high compression in
>> some common (maybe even the most common) use cases (better than current
>> compression)
>> webdav\main - it depends what the user is doing\transfer, could achieve
>> high compression ratio as well
>>>> On Thu, Mar 02, 2017 at 06:53:23PM +0200, Snir Sheriber wrote:
>>>>> This series of patches allows compression of messages over
>>>>> selected spice channels
>>>>>
>>> Which channels did you try?
>>> Do you have statistics for various channels?
>>> I suppose for instance that for sound and display (which are already
>>> compressed)
>>> is not much worth doing while for instance cursor and usb would gain
>>> more (cursor shapes are not currently compressed).
>>>
>>>>> Few notes:
>>>>>
>>>>> *Currently lz4 stream and regular compression are in use for small and
>>>>> large
>>>>> messages accordingly. packets are being sent in common msg type that was
>>> Why did you do such distinction for small and large?
>>> Have you tried to just use stream all the time?
>> Stream compression limitations.. the very large one are pretty rare..
>>>>> added,
>>>>> and it utilize previous compressed message structure.
>>>>>
>>>>> *The stream compression & decompression dictionary is based on previous
>>>>> messages,
>>>>> there for messages that has compressed\decompressed in stream mode are
>>>>> being saved
>>>>> in continuous pre-allocated buffer and a pointer is used for tracking
>>>>> current
>>>>> position.
>>>>>
>>> Wouldn't be worth trying to use framing functions?
>>> LZ4 framing functions already handle the buffer for you. They also
>>> support flush which would be useful to support large messages (looks
>>> like reading the code we are limited to 64K).
>>> Would be also possibly worth trying to move the channel compression
>>> to lower level (RedsStream) to compress everything and possibly
>>> multiple messages together.
>> I tried it before on packages that was captured from spice channels
>> iirc performance wasn't bad but stream compression was better.. (cpu\
>> latency & compression rate)
>> I guess it is possible to do something like that (similar idea as the
>> tls ?),
>> i would say that if it will be implemented in lower level the framing
>> lz4 may
>> be a wiser choice.
>> btw this idea has came up before but i was slightly preferred the
>> current one that
>> utilize the protocol messages and the already exists compression
>> structure. i guess it
>> would take some time but i could try it that way also and make measurements
>> afterwards..
>>
> I did some quick tests with framing, just a small program printing some
> information while compressing. I was quite disappointed on the way it works.
> Basically it cache the compressed data till you flush or end (which does
> a flush) your frame then frame the compressed data and reset the history
> (so restarts again). There is a linked flag but still the history is reset.
> So basically it does buffering, normal (not streamed) compression and framing.
> As flushing is needed to avoid big latency issues resetting the history
> kills the compression.

yes, actually it could be fine with webdav... (allowing some latency) 
probably
not for the rest :/

>>>>> *Currently all channels are allowed to be compressed, we might want to
>>>>> avoid
>>>>> compression for some channels (for good or just in specific cases)
>>>>> ***please
>>>>> notice that usbredir compression was not revert yet so meanwhile i added
>>>>> 2
>>>>> small
>>>>> patches to disable its compression caps.
>>>>>
>>> Why you had to disable usb ?
>> The idea is to revert the usbredir-compression if these patches would be
>> upstream eventually, so it's just to avoid double usb compression for now..
> Yes, make sense.
>
>>>>> *Multiple clients- basically it should work with more than one client,
>>>>> although adding
>>>>> compression/decompression to just part of the clients could theoretically
>>>>> make it
>>>>> worse (good for compression performance testing though)
>>>>>
>>> It's not clear this point
>> ahh, never mind it wont work on the impotent channels anyway
>>>>> -If someone has encountered issues with the combination of compression
>>>>> and
>>>>> other spice features please let me know
>>>>> -Suggestions and comments are welcome, especially for improving the
>>>>> messages sending  :)
>>>>>
>>>>> Snir.
>>>>>
>>>>> Spice components:
>>>>> server,client,spice-common,spice-protocol
>>>>>
>>> Frediano
>> Snir.
>>
> Wondering if is possible to save the entire stream in a way that is easy
> to compute possible different compression framing and schemas.
>
> Frediano