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