Paring Down “Watt’s Switched On” on a Client’s Network

As part of carbon reduction for a client, Creative Concern, I’ve been working on:

• leased-line router consolidation
• server consolidation
• network switch consolidation (using D-Link’s line of green ethernet switches)
• power management on desktop computers (no screen saver but screen backlight switch-off, sleep when idle, scheduled shutdown at 6pm)
• night-time network scan to determine devices not shut down

The network scan is a particularly fun one: MacOS and modern printers all respond to multicast DNS, and so finding devices which are switched on is quite simple. Every night an email is sent (by one of the servers which stays on 24/7) to the staff naming and shaming the devices which were left powered up:

#!/bin/bash

avahi-browse -at \
  | cut -c 14-59 \
  | sort \
  | uniq \
  | mail -s "Named and Shamed: devices left on overnight" everyone@client

I’ve removed a few grep -v statements which filter out things like the servers which are meant to be left on overnight, but those are the essentials.

Having fitted a smart meter the client has access to power usage graphs and history, and I’m pleased to be able to report that they look to be on course for a 10% saving in 2010! Here is the screenshot from the meter just now:

I am still to explore:

• consolidating the font, finance and project management system servers (currently all require different versions of OS X)
• wireless network access point consolidation (can just two APs cover the entire office area?)
• more network switch consolidation (eliminate all desktop switches?)
• CPU scaling on servers to use power-saving governors outside office hours

I estimate that we might achieve an additional 10% saving if we can do all these things, but could be hampered by what’s feasible in the office with the technologies available.

Compression Algorithms: an argument for energy efficiency

There’s been a lot of talk both recently and in years passed about LZMA compression. With any compression algorithm come benchmarks and these are often in the form of compression-rate, decompression-rate and compression-ratio:

compression rate

Basically this is “less time spent waiting for the compressed output to be generated”. Where data must be sent real-time, or where the compression process adds latency or reduces the bandwidth of transmitting data, a higher compression rate is desired.

decompression rate

Having received a copy of the compressed data, a higher decompression rate is “less time spent waiting for the original output to be generated”. This can be important where mobile devices are decompressing data (e.g. streamed video) so that less CPU power is used.

compression ratio

How much smaller is the compressed file? The higher the ratio the “better” the algorithm, but not all algorithms perform equally on all sorts of data. Specialist algorithms tailored to the kinds of data being crunched are common (for example, lossless audio compression algorithms tend to outperform general compression algorithms in their niche).

I remember the gradual change from gzip compression to bzip2 which started to happen at the end of the 1990s and continued at the start of the 2000s. Back then I had a Pentium-II 333MHz as my main workstation and a 10Mbit university-provided Internet connection. Sometimes it would be quicker to download a larger gzip file than wait for the much slower bzip2 algorithm to complete its decompression. Today things are much the same: running Faelix means I have much more Internet bandwidth at my disposal than I could need for getting files, but CPU speeds are that much quicker that I’d now consider the bzip2 file over the gzip.

However, my position as a content provider (the owner of an ISP) and the asymmetric nature of the CPU costs of LZMA have changed my thinking on this subject. LZMA achieves better compression, typically, than bzip2 or gzip but is much slower to compress data than either of them. However, LZMA might be very slow to compress but it is much faster than bzip2 when decompressing data. This leads to the question, “Why do we compress data?”

• smaller storage requirements
• smaller transport requirements

The benefits this brings:

• lower cost of storage
• possibly leads to lower energy consumption for storage
• lower cost of transport
• transport of data across communications links will take less time
• better use of capacity of existing communications links (more customers served)
• possibly leads to lower energy consumption for transmission of data

An algorithm with better compression will have lower transport/storage costs. Assuming that an algorithm which is fast under decompression uses fewer instructions per bit of decompressed data output, a faster decompression is also more “ecologically sound”. This is a bit of a hand-waving argument now, but I’m curious enough that I may experiment and confirm this hypothesis with actual data. In the use case of one large, pre-compressed file being made available to a large number of users, LZMA would appear to be a strong contender to replace bzip2 or gzip when ranked with a benchmark of “energy efficiency”:

• compression, though slow (therefore assumed to be energy-costly), is a one-time operation
• transmission is smaller, and is a per-user operation
• depression is fast (therefore assumed to be more energy-efficient), and is a per-user operation

Research to follow, I think…