Re: [Spice-devel] [RFC] Spice channels compression

> On 7 Mar 2017, at 16:37, Frediano Ziglio > wrote: > >>> >>> >>> Hi Snir, >>> >>> Regarding compression and another topic recently evoked, endianness, I >>> wonder >>> if encoding using LEB128 had been discussed? >>> >>> LEB128 encodes any value below 128 as 1 byt

Re: [Spice-devel] [RFC] Spice channels compression

> > > > > Hi Snir, > > > > Regarding compression and another topic recently evoked, endianness, I > > wonder > > if encoding using LEB128 had been discussed? > > > > LEB128 encodes any value below 128 as 1 bytes, any value below ~16000 as 2 > > bytes, and so on. It is size and endianness indepe

Re: [Spice-devel] [RFC] Spice channels compression

On 03/07/2017 12:59 PM, Christophe Fergeau wrote: On Mon, Mar 06, 2017 at 02:05:14PM -0500, Frediano Ziglio wrote: 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 se

Re: [Spice-devel] [RFC] Spice channels compression

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 addit

Re: [Spice-devel] [RFC] Spice channels compression

On Mon, Mar 06, 2017 at 02:05:14PM -0500, Frediano Ziglio wrote: > > > 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 jus

Re: [Spice-devel] [RFC] Spice channels compression

> > 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 a

Re: [Spice-devel] [RFC] Spice channels compression

> > Hi Snir, > > Regarding compression and another topic recently evoked, endianness, I wonder > if encoding using LEB128 had been discussed? > > LEB128 encodes any value below 128 as 1 bytes, any value below ~16000 as 2 > bytes, and so on. It is size and endianness independent. This means that

Re: [Spice-devel] [RFC] Spice channels compression

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,

Re: [Spice-devel] [RFC] Spice channels compression

Hi Snir, Regarding compression and another topic recently evoked, endianness, I wonder if encoding using LEB128 had been discussed? LEB128 encodes any value below 128 as 1 bytes, any value below ~16000 as 2 bytes, and so on. It is size and endianness independent. This means that we can extend

Re: [Spice-devel] [RFC] Spice channels compression

> > 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

Re: [Spice-devel] [RFC] Spice channels compression

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 On Thu, Mar 02, 2017 at 06:53:23PM +0200, Snir Sheriber wrote: > This series of patches all

[Spice-devel] [RFC] Spice channels compression

This series of patches allows compression of messages over selected spice channels 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 added, and it utilize previous compressed message str