Subject: [lemonade] compress=deflate: why turn compression off?

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 29 Jun 2006 11:01:38 +0200

Hi,

someone (I didn't catch the name, sorry) suggested that being able to 
turn compression off again (via something like "COMPRESS NONE") is 
desirable. However, I didn't hear any use case for that. Could the 
person who wanted the feature speak up? Why?

I didn't write that up yet, because it's tricky. Adds some otherwise 
unnecessary server state, so the cost needs to be judged against the 
value. Use cases will be helpful.

(Up to now, the client can turn off client-to-server compression and the 
server can turn off server-to-client compression, but the client cannot 
direct the server to turn off server-to-client compression.)

Arnt

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: "Stephane H. Maes" <[email-masked]>
Date: Thu, 29 Jun 2006 02:03:40 -0700

Arnt,

I would like to have that capability for battery consumption reasons.

Stephane 

_____
Stephane H. Maes, PhD,
Director of Architecture, Mobile, Voice, and Communications Platforms, Oracle.
Ph: +1-203-300-7786 (mobile/SMS); Fax / Office UM: +1-650-607-6296
e-mail: [email-masked]
IM: shmaes (AIM/Y!/skype) or [email-masked] (MSN Messenger) or [email-masked] (Google)

-----Original Message-----
From: Arnt Gulbrandsen [mailto:[email-masked]] 
Sent: Thursday, June 29, 2006 2:02 AM
To: Enhancements to Internet email to support diverse service environments
Subject: [lemonade] compress=deflate: why turn compression off?

Hi,

someone (I didn't catch the name, sorry) suggested that being able to turn compression off again (via something like "COMPRESS NONE") is desirable. However, I didn't hear any use case for that. Could the person who wanted the feature speak up? Why?

I didn't write that up yet, because it's tricky. Adds some otherwise unnecessary server state, so the cost needs to be judged against the value. Use cases will be helpful.

(Up to now, the client can turn off client-to-server compression and the server can turn off server-to-client compression, but the client cannot direct the server to turn off server-to-client compression.)

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 29 Jun 2006 11:28:54 +0200

> I would like to have that capability for battery consumption reasons.

Explain?

All the evidence I've seen so far is that receiving data data compressed 
requires less CPU than uncompressed.

(FWIW, for those who want to try it themselves and have a linux laptop 
with ttcp, gunzip, ACPI support and the right sort of radio, some 
rough-and-ready testing is quite easy. Via ACPI you can get battery 
status and drain rate with fair accuracy, so all you need to do is log 
it to /tmp or some other RAM disk every second, then do a long series 
of transfers and see what eats more power. I've tried it, but only with 
802.11b and an intel cpu.)

Arnt

---

From: "Stephane H. Maes" <[email-masked]>
Date: Thu, 29 Jun 2006 02:35:09 -0700

When under battery strain, I may selectively request to get a content compress and the turn it off. I have heard arguments with both point of view on what cost the most.   

What were the results of your measures?

Stephane

_____
Stephane H. Maes, PhD,

-----Original Message-----
From: Arnt Gulbrandsen [mailto:[email-masked]] 
Sent: Thursday, June 29, 2006 2:29 AM
To: [email-masked]
Cc: Stephane H. Maes
Subject: Re: [lemonade] compress=deflate: why turn compression off?

Explain?

All the evidence I've seen so far is that receiving data data compressed requires less CPU than uncompressed.

(FWIW, for those who want to try it themselves and have a linux laptop with ttcp, gunzip, ACPI support and the right sort of radio, some rough-and-ready testing is quite easy. Via ACPI you can get battery status and drain rate with fair accuracy, so all you need to do is log it to /tmp or some other RAM disk every second, then do a long series of transfers and see what eats more power. I've tried it, but only with 802.11b and an intel cpu.)

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 29 Jun 2006 12:14:06 +0200

Stephane H. Maes writes:
> When under battery strain, I may selectively request to get a content 
> compress and the turn it off. I have heard arguments with both point 
> of view on what cost the most.
>

Some disclaimers first.

1. VERY ROUGH AND READY.

2. 802.11b IS VERY DIFFERENT FROM MOBILE SPEEDS.

3. I USED AN INTEL CPU.

In other words, it was just enough for me to look at whether the issue 
warranted serious consideration, nothing more.

I took all the files I've downloaded or received via email since the 
last time I cleaned my ~/tmp directory. For each file, I transferred it 
lots of times to my laptop using ttcp, without compression, with gzip 
-1 and gzip -9, and checked the battery status using /proc/acpi on the 
receiver. (This on a Lifebook S6010, which reports battery status well. 
The laptop was otherwise idle.)

For some files, the -9 used the least battery power per transmission. 
For some, the -1. Uncompressed never won discernibly. There were some 
ties. I couldn't see any pattern (which would have interested me, since 
that could enable the client to predict that the server should not 
compress).

I kept the shell scripts, in case anyone wants to do this with a real 
radio and wants a starting point.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 29 Jun 2006 12:35:14 +0200

> of view on what cost the most.

Forgot to answer this.

Perhaps the distinction between compression and decompression got lost 
somewhere along the line?

It's easy to find files that require lots of CPU (and battery power) to 
compress. It's plausible that in some (or many?) cases, 
compress+transmit is more expensive than transmit. But that's 
irrelevant. Usually the sender isn't battery-constrained, and even when 
it is, the sender already has the possibility to adjust its compression 
expense up and down, all the way down to zero.

Decompression is the issue. Decompression seems (from what everyone 
says) to be a win-or-even in terms of power. Can you (or anyone) find 
exceptions?

Arnt