[Beowulf] Power consumption for opterons?
James.P.Lux at jpl.nasa.gov
Thu Mar 11 11:10:16 EST 2004
At 08:39 AM 3/11/2004 -0500, Robert G. Brown wrote:
>On Thu, 11 Mar 2004, Alex Martin wrote:
> > I find you numbers a bit surprising still As part of our latest
> > I looked up the power consumption in the INTEL/AMD documention for the
> > various processors under consideration:
> > Opteron 240-244 82.1 W
> > 246-248 89.0 W
> > I think these numbers are meant to be maximum?
>You've got me -- dunno. I can post a digital photo of the kill-a-watt
>reading if you like (I was going to take a camera down there anyway to
>add a new rack photo to the brahma tour). I can also take the
>kill-a-watt and plug in an electric light bulb or something with a
>fairly predictable draw and see if it is broken somehow.
>Right now a system in production work is plugged into it -- I'll try to
>retrieve it soon and plug one of my new systems into it so that I can
>run more detailed tests under more controlled loads. I don't know
>exactly what kind of work is being done in the current jobs being run.
>One advantage may be that the cases are apparently equipped with a PFC
>power supply. The power factor appears to be very good -- close to 1.
>This may make the power supplies themselves run cooler, so that the
>power draw of the rest of the system IS only 20 or so more watts. The
>systems also have a bare minimum of peripherals -- a hard disk (sitting
>idle), onboard dual gig NICs (one idle) and video (idle).
Those power supplies are impressive PFC wise..
I'd venture to say, though, that the rated powers are peak over some fairly
short time. The Kill-A-Watt averages over some reasonable time (a second
or two?), so you could actually have an average that's half the peak.
Everytime there's a pipeline stall, or a cache miss, etc, the current's
going to change. We used processor current to debug DSP code, because you
could actually see interrupts come in during the other steps(FFT = very
high power, sudden drop for a few microseconds while ISR is running). You
could also accurately time how long each "pass" in the FFT took, since the
CPU power dropped while setting up the parameters for the next set of
To really track this kind of thing down, you'd want to hook a DC current
probe around the wires from the Power supply to the motherboard. Then,
write some benchmark program with a fairly repeatable computational
resource requirement pattern. Look at the current on an oscilloscope.
I suspect that onboard filtering will get rid of variations that last less
than, say, 1-10 mSec, so a program that has a basic cyclical nature lasting
10 times that would be nice.
Ideally, you'd probe the current going to the CPU, vs the rest of the mobo,
but that's probably a bit of a challenge.
Another experiment would be to write a small program that you KNOW will
stay in cache and never go off chip and measure the current draw when
James Lux, P.E.
Spacecraft Telecommunications Section
Jet Propulsion Laboratory, Mail Stop 161-213
4800 Oak Grove Drive
Pasadena CA 91109
Beowulf mailing list, Beowulf at beowulf.org
To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
More information about the Beowulf