The Energy Zarr Blog

Telepresence – The Next Best Thing to Being There

Just about every week I step onto some form of aircraft - mostly turbine powered kerosene burning jets.  I leave my carbon footprint trailing all over the friendly skies and often reflect on that fact.  After running for a flight and finally settling into my generously spacious coach seat, I get a chance to breath and relax.  My mind often goes to past episodes of Star Trek or other futuristic science fiction shows where people simply press a button and are instantly connected via real-time video communications with anyone, anywhere - even between star systems (a bit of a physics problem there with the faster-than-light information propagation thing, but I digress).

So, this week I opened a copy of USA Today and found an interesting article in the Money section on the re-emergence of Video Conferencing technology.  In a world where reducing energy consumption and the dependence on carbon based fuels is paramount, it would seem to me a no-brainer to shove some horsepower in the form of incentives into the video conferencing industry.  Companies such as Citrix and Cisco are already providing services to the masses that are available via the web.  Services such as GoToMeeting and WebEx provide a shared desktop environment for viewing each other’s Power Point or by using shared drawing and mark-up tools. This is extremely handy when needing a quick meeting to "touch base" which in my industry seems to be every hour.

On the higher end are companies such as Tandberg and Polycom who supply specialized equipment, services and software to enable multi-user high-definition audio / video conferencing or "telepresence."  These systems are really something and are geared to the corporate level of service. However, they often require a significant investment in equipment and infrastructure to take advantage of the technology as well as having issues with interoperability between competitors.

Beyond cost, there are a few issues with telepresence that has limited the adoption of the technology.  One is simply "eye contact" and shaking hands.  As humans we extrapolate a great deal of information by watching body language - especially someone’s eyes.  Body language can be extremely telling when you are in the same room.  Place someone in front of a camera, and you may not see the detail or the body language may be influenced by the Hawthorne Effect also known as the "Observer Effect."  A person may act differently if they feel they are being "watched." The knowledge that the camera is sending a video stream to possibly unknown individuals or even being recorded will change a person’s natural behavior.  This could possibly interfere with what would be a normal conversation.

As people get used to the idea of telepresence, those issues will fade, but today the lack of ubiquitous access and standards continues to plague the industry.  I would love to have a camera built into one of the monitors in my office so I could simply answer a call and "see" the individual - not to mention instantly share information as you would in person.  Seeing an individual over a video link reminds you of your connection to them and builds the relationship through repeated virtual "in-person" meetings.  However, many systems cannot interoperate and limit many calls to pre-arranged meetings.  Not that arranging a meeting before hand is bad, but it can limit the ability to impulsively place a video call to someone. 

As the telepresence industry evolves, the issues with interoperability and viewer consciousness will be solved or fade away.  By that time I will probably have a wall-size OLED display and a persistent connection with my comrades world-wide.  People all across our organization will be able to walk by my virtual "cube" and see if I’m in - maybe not such a great idea if I’m trying to get something time-critical completed! Something to think about... but when it happens I will surely miss the posh and lavish comforts of modern airline travel. Till next time...

The True Cost of an Internet “Click”

Did you ever stop and think about how much energy you consume? Yes, you personally... and your family.  I think about it all the time.  I turn off lights, adjust the thermostat, consolidate my trips to reduce fuel consumption and turn off the TV when not watching.  I’m sure you do the exact same thing.  The cost of all forms of energy is continuously increasing especially in the last few years.  But have you ever thought about how much energy you consume when you click a link on a web page or send an email... probably not - and neither have I until now. 

I do a great deal of research into how efficiently energy is used in various systems and processes and I’m constantly on the Internet accessing websites.  Recently in a meeting, a fellow executive made a comment that hiding behind the cost of your Internet broadband connection and home computers were hidden energy drains.  These were the infrastructure and servers that manifest the information super-highway.  How much power was consumed because you wanted to see the latest top video on YouTube?  What if you didn’t click it? How much power would you save? How much carbon dioxide did you save from our atmosphere?  I thought, "Wow" what an interesting question...  Now, can we answer that question? That’s the question.  This is a monumental task... and difficult to estimate (but that’s never stopped me before), so we’ll have to examine exactly what happens when you access a website and make some assumptions to reach a reasonable conclusion.  Here goes...

First we need to consider what happens when you "click" a link in a browser.  The browser must first connect to the target server so it can request the page associated with the link in the page.  This is accomplished using Transport Control Protocol (TCP) and is similar to placing a phone call to the server.  Once the server "answers" and establishes the connection, the browser forms a request packet for the page tied to the link.  This request asks the server to send the contents of the page back to the browser.  If the page address is valid, the server then responds with a stream of packets that identify it as a valid server response along with all of the Hypertext Markup Language (HTML) contents plus other information such as scripts, meta-data, formatting and others.  Once all of the contents of the request are delivered to the browser, the connection is ended and the information is rendered into something the user can see and read.  Modern browsers actually make multiple connections and requests simultaneously to fill in images and other sections of the page.  This makes the rendering much faster and provides a smoother appearance to the user (See below).

The process above takes place between two computers usually separated by a vast distance.  It is very reasonable to expect most web accesses made by a user reach servers that are located anywhere from hundreds to thousands of miles away.  Between the two computers is a vast network of switches and routers - a "highway" for the data packets.  Like railroad trains, the packets travel from your cable modem over your cable network (the local spur line) to the central office.  There the packets are switched to higher bandwidth fiber optic cables (main rail lines) using very short pulses of laser light which travel extremely far.  The packets may transition several major switching stations before being routed to the local network connected to the distant server.  What’s interesting is that the messages between the computers will often require multiple packets and, like trains, may arrive at different times out of order from what was sent.  This occurs due to traffic conditions along the way, again like trains on a railroad, the data routers find the most efficient path to deliver the packets resulting in varying arrival times.  One job of the receiving computer is to re-order the information and pass it on to the high level software for interpretation.

All of the technology to accomplish this transaction requires power - from the computers at both end (yours and the distant server) to the networking equipment and networks in between.  As mentioned earlier, to estimate the power consumed in loading a web page we need to make some assumptions.  For this estimate, we’ll ignore the power in the local computer and home network infrastructure - this would be considered already spent in the local budget regardless of the Internet accesses.  We will only consider power consumed by everything external to your location. 

Next we’ll need to consider the page contents and how many packets would be required to move the information back to your browser.  Our "typical" page will have no video since that is most often streamed and holds the connection open (like a long phone conversation with your best friend - only they do all the talking).  It will have 3 graphics that average 100kb each and about 5000 characters of information (e.g. a Wikipedia or news page).  The total page contents will require approximately 310kb to be transferred from the server to the browser.  Upstream from the browser, there will be at least 4 requests (1 for the page, 3 for the images).  The requests will occupy only about several hundred bytes of data, so in total the one web page request will move about 315kb of data (which includes all the connection overhead) between the two computers. 

Now that we have an understanding of how much information is transferred between the two machines, we need to examine how much additional networking equipment the information crosses and the power consumed.  We’ll assume the cable head end has a modem, a switches and a router - totaling approximately 200 watts.  The high speed connection on the Internet side of the router probably has a fiber link with an interface box (another 100 watts).  We’ll assume the packets make 3 jumps to other routers along the way.  Each jump will have 2 fiber boxes and a high speed router (to simplify) for a total of 300 watts for each jump.  The server farm will have one fiber box, a router and switches which adds an additional 300 watts.  The total network power for that link is approximately 1500 watts.  Last, we need to consider the average power of a modern blade server - let’s assume it averages around 50 watts.

Now that we have a scientific guess at the power numbers, it gets a bit complicated.  We need to know how much time your data used each piece of equipment so we can get watt-hours, a measure of energy.  Let’s examine the various speeds starting with the cable side.  Typical Data Over Cable System Interface Specification (DOCSIS) cable modem will have an aggregate bandwidth of around 152 Mbps (Mega-bit per second) down stream and 108 Mbps upstream (to the server).  To simplify the calculation for time that the packets stay on that leg of the network, we’ll use the upstream data rate of 108 Mbps.  We’ll also assume the fiber legs are OC-12 (Optical Carrier 12) with data rates of around 601 Mbps (622 Mbps - 21 Mbps overhead).  The final leg inside the web server’s infrastructure will most likely be a 1 Gbps (gigabit per second) Ethernet path.

To normalize all of these varying power-speed numbers, we’ll turn to a metric used by my company, National Semiconductor to rate the power consumption of interface devices.  This breaks down the speed and power numbers into one unit of measure in units of energy per bit (Joules/bit - see PowerWise® Solution Metrics).  I’ve also mentioned this method in a previous blog (The Efficiency of Moving Bits) and it allows us to greatly simplify calculating all the various speed-power numbers.  Table 1 shows how we figure out the picojoules per bit for each hop the data takes. The total energy per bit is roughly 4.6 microjoules per bit.

Table 1 - Network Energy Consumption

Network Equip.	Power	Data Rate	pJ/bit Value
Cable (DOCSIS)	300 W	108 Mbps	2.8 uJ/bit
Fiber (OC-12)	900 W (3 x 300)	601 Mbps	1.5 uJ/bit
Ethernet	300 W	1000 Mbps	0.3 uJ/bit
		TOTAL	4.6 uJ/bit

The server blade usage will vary, but we’ll assume a fully loaded server providing 2000 pages per second.  Your page will then occupy one access of that or 1/2000 of 40 watts or 0.02 watt-seconds (Joules).  Now let’s see how this all adds up for your web page view.

We concluded that the average page request occupied about 315,000 bytes of data.  That’s 2.52 x 10^6 bits.  The total energy required for the transaction was 4.6 x 10^-6 Joules per bit.  Multiplying these two numbers result in 11.52 Joules.  We add in the server energy of 0.02 Joules for a total of 11.61 watt-seconds (Joules) for each page view.  Again, this is not streaming video (I’ll look at that in a future blog post), but a static web page access from a server.  If you now multiply that single access by 1 million every second (a medium city’s population browsing the web), you get an energy consumption number of around 11.610 kilowatts an hour to keep the data moving...  enough energy to power roughly 13 US households for a month!  For you viewing 100 pages in a day, that would be about 323 milliwatt-hours of energy - or the equivalent of watching TV for about 10 minutes - and interesting thought.

As expected, it seems that the contribution of any individual is extremely small, but the sum of the population makes a much larger impact.  Maybe you’ve got a better estimate or have looked at this before more closely... let me know what you think!  Till next time...

The Efficiency of Moving Bits - Part 2

In my last post I talked about life as a designer in the early 1980’s… it’s funny to look back and think of what we thought was “amazing technology” – some more of which I’ll discuss today.  I’m sure someone reading this could comment on engineering marvels of the 1960’s as well.

I’m going to continue my discussion on moving bits with some comparisons of bus architectures from that time and today.  We’ll take a look at how much has changed and the evolution of connecting systems and subsystems together.  I’d like to start with the S-100 bus which was essentially the Intel 8080 processor’s external bus, but not many engineers might remember that architecture.  I had friends that owned (yes, owned) the IMSAI 8080 and built automated amateur radio repeaters using these machines as controllers.  My first “computer” designs used the ISA bus made famous by IBM in the PC released in August of 1981 (I purchased one of those early machines and was the first geek on the block to show it off!).

The ISA or Industry Standard Architecture bus was not a standard (yet) when IBM introduced it in their PC.  Actually, the fact that IBM published a technical manual that including a listing of the BIOS (Basic Input Output System) source code and complete schematics, made it quite easy to clone…  I still don’t understand that decision.  This basic 8 bit bus originally ran at 4.77 MHz (like my old machine did), but later was enhanced and supported an 8 MHz clock, so every 250nS, 8 bits were transferred over the bus.  To actually move data into RAM or read an I/O address several cycles of the bus were required to latch the address, allow for settling of the bus, and give time to the peripheral to respond.

As processors improved in speed, buses needed to keep up.  The first logical step was to simply speed up the clock (as IBM did from the original PC 4.77 MHz clock to the 8 MHz clock in the XT) or use both edges of the clock.  Additionally, by making the bus “wider” with more communication lines (e.g. 8 bits to 16 bits and beyond) also improved performance.  The bus wars raged for years getting ever wider and faster.  As engineers, we continued to look for ways to move more data between subsystems and this led to us bumping into the physical laws of nature… primarily skew between bus lines and waveform distortion.  It was even more difficult if you wanted to extend the bus farther than the 10 inches inside the chassis, which at times seemed almost impossible.

It seemed counter-intuitive that the solution would be to move away from wider buses and serialize the data, but this is exactly what happened.  As the speed of the buses increased, there was little margin between each communication line (i.e. data, address, or control signals).  A tiny amount of skew would cause errors in the transfer of data.  Additionally, the mechanics of connecting large numbers of lines to a circuit card added expense.  Serializing the data reduced the number of mechanical connections, reduced or removed issues with skew, and had one additional feature – it reduced the overall power consumed.  This was accomplished by moving away from large voltage-swing technologies such as TTL and using devices based on LVDS.  Additionally, bus designers could now have point-to-point connections to each peripheral due to low connection count (e.g. PCI Express) which greatly improves bus bandwidth.  An example is the DS92LV16 SERDES (Serializer / Deserializer) transceiver. This device simply takes 16 data lines, serializes them, embeds the clock transports it to another DS92LV16 which reconstructs the 16 data lines and clock.  This is a transceiver so it has an upstream and a downstream and is LVDS based so it uses 2 wires for each path (4 wires total).

To compare old bus architectures such as ISA with serialized LVDS, we’ll need to define the parameters.  In my old ISA designs, I decided to use buffers to drive the data over the back-plane (rows of 62 pin edge connectors).  I needed enough drive to make sure the loading caused by a full complement of circuit cards would not degrade the speed of the edges.  The buffers were industry standard 74LS24x TTL level buffers.  I needed one 74LS245 and two 74LS244 buffers to drive the address lines.  There were others for control and bus management, but we’ll use only the 74LS245 for simplicity.  The bus was about 10 inches long (0.254 meters) and the transceiver consumed about 250 milliwatts (with a supply current of roughly 50 mA at 5V).

If we apply the equation from last week’s blog post to calculate energy per bit-meter for the old ISA bus we get 15.4 nJ/bit-meter.  This is using the bus clock rate, not the bus transfer rate. The calculation for the serialized bus running full duplex to the peripheral, we get 1.6 nJ/bit-meter over the same circuit card – an almost 10 to 1 improvement in data transfer energy efficiency.  These calculations are for a single end of the connection.  This ISA example does not take into account all the supporting bus electronics since it was a shared bus.  The serialized bus is much simpler since it connects directly to a single peripheral and can have multiple peripherals communicating with the host at the same time.

If you look deeper, the older parallel bus architectures are even less efficient at moving data than stated above.  If you think about extending the bus to an external chassis (i.e. 1 meter or more), the problems really pile up for parallel buses.  Serialized buses simplify everything from the connector to cable (with less wires) and even the number of connections to processors or FPGAs and are far more efficient at saving energy when moving data.

Let me know your stories or opinions by commenting on this blog or dropping me an email.  I’d love to hear from you.  Until next week…

The Efficiency of Moving Bits

I started my engineering career in the early 1980’s as a designer for a modem company.  It was an amazing time since the Internet was growing in leaps and bounds and personal computers were making their big debut.  In those days the price of modems was similar to the price of gold – roughly $1 US per bit per second.  That’s meant if you wanted a 9600 bps modem (a museum piece today), you’d pay roughly $10,000 US for it.  Those were profitable times. 

The modems of those days were in rack chassis (no custom modem ICs existed yet) with hundreds of 74 series logic devices along with discrete analog filters, modulators, demodulators and line drivers made from op-amps and transistors.  The box weighed about 20 pounds and had a gigantic 50W power supply.  Not only were those early modems expensive to buy, they were very inefficient in moving the bits in terms of the power consumed. 

Things have improved over the last 25 years to where a household network has many high performance personal computers or game stations all connected together with 100 Mbps unshielded twisted pair (UTP) Ethernet drops or even wireless 802.11 access points.  These connections are managed by an Ethernet packet switch and typically a router / firewall connecting to a cable modem to provide upwards of a 10 Mbps connection to the Internet. 

But how would we compare those early (or even more recent) communication technologies to what’s available today.  How should we compare how efficient one technology or component is over another for moving information? Equation 1 provides a simple formula for creating a metric that does just that.    Power is in watts and the transfer rate (fb) is in bits per second.  The variable “ch” is the number of channels in a system or device to normalize the result to a single channel.  The result is the data transfer efficiency (eb) in joules per bit (J / bit). 

This equation normalizes all coding and signal processing which allows you to compare how good a technology (system or device) is at using the least amount of energy to move a bit across a medium error free (i.e. a bit error rate or BER of less than 10-12).  If you want to normalize the length as well,  simply divide by the length (in meters) of the connection and the result is Joules per bit-meter (J / bit-m) as shown in Equation 2.  This allows technologies that drive various distances to be compared.

Let’s use equation 2 to calculate the efficiency of that old modem I worked on in the 1980’s.  It was capable of moving 9600 bits per second over 15,000 feet (4572 meters) using roughly 50 watts.  That yields a data transfer efficiency of 1.14 microjoules per bit-meter.  So every bit used roughly 1.14 uJ of energy to move it from my office to the telecom central office 3 miles away (worse case).   If the telephone switch was in the office building next door (1000 feet away), the number goes up to 17.1 uJ / bit-meter.  Compare this with a modern Data Over Cable Interface Specification (DOCSIS) cable modem which uses about 5 watts of power, goes the same distance (using coaxial cable) and moves up to 43 Mbps downstream (using 256 QAM) of error free data.  This equates to a data transfer efficiency of 25.4 picojoules per bit-meter.  That is an multiple improvement in transfer efficiency of more than 40,000 over the old modem technology – an amazing accomplishment.

Next time I’ll cover more on data transfer efficiency and we’ll look at bus architectures and interface technology.  If you have any thoughts (agree / disagree / don’t care), please drop me a comment here on the blog!  Thanks for reading and I hope to hear from you soon!