Ethernet energy efficiency

How power-hungry are various permutations of Ethernet on modern MacBook Pros? Tests performed and written up by Jeroen van der Ham and Iljitsch van Beijnum.


For some reason, we thought it would be a good idea to make the students of the System and Network Engineering master program test whether various permutations of IPv4/IPv6, energy-efficient Ethernet (eee) and jumboframes use more or less power. While the students were busy measuring, we were bored so we decided to run the same tests ourselves using our MacBook Pros (with Retina Display®)—Jeroen the 15″ mid-2012 model and Iljitsch the 13″ late 2013 model. These computers are too thin to house an Ethernet port, so we used Apple’s Thunderbolt – Gigabit Ethernet adapter. We looked at the number of milliamps taken from the battery to see how much power the entire system used during various tests.

We didn’t realize it at first, but the most surprising result was actually the first one, looking at system power use with the adapter plugged into the computer, but without attaching a network cable. This increased system power use by 300 mA, or about 3.4 Watts. On the 15″ MBP this is already significant, increasing power use from 1250 to 1550 mA. But the 13″ MBP only used 370 mA without the adapter plugged in, so its power use almost doubled after plugging in the adapter!

Could it be that the secret to the long battery life of Apple’s recent laptops is the fact that they come without an Ethernet port?

We continued our testing trying different possibilities with Energy Efficient Ethernet (eee) turned on or off. Students in 2012 already looked at the general impact of eee on energy usage for clusters. They found that it provides an energy saving of up to 40% in switches, depending on the amount of traffic. Energy usage goes up when traffic goes up, but it already maxes out when you are using roughly 40% of the bandwidth. We confirmed this in our testing: there is not much difference with eee when the interface is idle, or with full traffic.

More significant energy savings started to appear when we enabled jumbo-frames (MTU 9000). The amount of data that goes through the adapter remains virtually identical, but with only one-sixth as many packets per second, the impact of per-packet overhead is greatly reduced, and this shows in the energy consumption. With full traffic in one direction this saves you over 10%. These savings also add up if you have traffic in both directions, in our experiments we saw a savings 16-19% for a bidirectional fully-utilized link.

Not surprisingly, the biggest difference in energy usage is to scale down the interface speed. When we forced the interface down to 10Mbps we saw a saving of up to 49% with full utilisation. Then again, if you’re sending a large file, it is going to take a lot longer, and you basically use a lot more energy, only more distributed over time.

The results of our measurements are in the table below, but note that our measurements (using the System Profiler battery current figures) weren’t very precise. The numbers give a pretty rough indication. If you want to do something serious with this data, perform your own experiments.

Total system power use MBP15 MBP13
Interface attached vs baseline



Baseline vs idle eee



Idle eee vs no eee



Idle eee vs iperf 1 Gbps TCP eee



iperf 1 Gbps TCP eee vs no eee



iperf 1 Gbps TCP jumbo eee vs no jumbo eee



iperf 0.5 Gbps UDP eee vs no eee



iperf 1 Gbps TCP bi-di eee vs unidirectional eee



iperf 1 Gbps TCP bi-di jumbo eee vs no jumbo bi-di eee



iperf 10 Mbps TCP no eee vs 1 Gbps



We did some extra tests to look at the impact of jumboframes on CPU use. Please note that our Thunderbolt-to-Gigabit Ethernet adapters don’t support TCP segmentation offloading (TSO). With 1500-byte packets the CPU utilization on the MBP13 was about 16%, with 9000-byte packets about 90%. Despite being idle more than 80% of the time, the CPU still ran at its advertised 2.4 GHz clock speed:


So the difference in CPU power use was 18% (7.9 W for 1500 bytes vs 6.4 W for 9000 bytes), despite the difference in CPU utilization only being 5%.