Wrapping It Up

With the multiple holidays just around the corner and finals week finally coming to an end as of yesterday, gifts are certainly not the only thing wrapping up around our neck of the woods at Sonoma State. And, with that being said, Stephanie and I certainly made some great strides forward after Thanksgiving, leading up until this past week and a half in which we took a break to focus on our finals.

On my end, we played chicken with redundancy, and upon further contemplation and research with Dr. Rivoire, we were able to figure out a much easier way to run our parsing scripts together that was in my previous update. In addition to this, the particular method we decided to pursue also could be done in a fraction of a second.

Rather than using a PERL script to open, run, and search through all of the files to match timestamps (Quite a lengthy process), which also proved extremely tricky for manipulating more files and larger files, we found a function in Bash Script programming that would allow us to ease this process. This Shell script will, instead, run each program (CPU, DISK, and AC) separately, kicking out a .txt file of edited results, and then use an independent function to merge these files together based on a matching time stamp. Although it sounds quite similar (which it is), the run time of this script is 2-3 seconds as opposed to minutes.....hours.....even days if the files were large enough, for the original method.

Wrapping (no pun intended) it back to the topic at hand, this helps us decisively in putting together Stephanie's large amount of collected data. Currently, our goal is to manually create a script that will give us file names that are much easier to use (and read) (Ex: Instead of 000000000001464cpu4-.txt, it would be much cleaner) , and then a final script that will allow the user to enter file names to be parsed and merged.

In conclusion, although we are not quite modeling the power consumption of GPUs, which is the function of the project, we are definitely well on our way to doing so. Once we can smooth out the couple of speed bumps in modeling the Disk, CPU, and AC, then we will aim to consistently and accurately model the GPU.

It certainly has been an event-FULL semester here in the computer science department of Sonoma State. From all of us here on the CREU team, we wish you all a wonderful holiday season! Please celebrate safely and tune in for updates in the coming weeks when we get started on the spring semester!

- Dr. Rivoire, Stephanie, and Vincent

Food, Wine, Football....and PERL?

After taking a long (and much needed) week off......wait, who am I kidding? Even over the course of being gone for an entire week for Thanksgiving, between family, football, great food, and even better wine, I still found time to dig into PERL. In hopes of reaching my end-of-the-semester goal of creating a final script that can parse through Stephanie's (extremely) large log/parse files, and finally running a full-on analysis of our systems, I downloaded Putty on my home PC and got straight to work after a (massive) Thanksgiving dinner. Did I mention we had one Thursday AND Friday? Jealous, I know.

In taking a step back from my previous statement, the script is actually complete. However, it is most definitely a "brute force" script, as we say in programming. In English, I took a much longer route with much more coding in order to complete the script. But, as with all things, there exists a much more efficient way for the code to work through itself. The current script, as it stands, opens and closes each of the 3 files for every iteration (aka run through) of the program, thereby extending the run-time of the program exponentially. Though with my test files it is approximately only a 10 minute wait on the run-time, if I were to attempt to run any of Stephanie's logs it certainly would take a few hours, at least. In other words, there is still some progress to be made. My next step as of now it to modify the script to, instead, open each of the files once and simply iterate through the lines repeatedly to find matching time stamps, rather than opening and closing each file every time. I'll be crying tears of thanks, metaphorically, when this script is all said and done.

But, on that note, what are you thankful for? I had plenty of things to be for over the past week: Family, friends, LOTS of football, food, wine, and a somewhat of a break in general from life. But, it didn't occur to me until the end of it that having the opportunity to learn PERL was also something I should be thankful for. I've mentioned it before, but it has been a welcoming opportunity to learn a new language that I thought I might be otherwise incapable of without CREU. So, in closing, thank you CREU and happy holidays to everyone - Cheers!

Cannot touch `cupcake': No such file or directory

Yes, calibration script, no cupcakes for you. Instead, victory cupcakes for me because I made it work! Nevermore did I want to dance, cheer and celebrate seeing that line. It meant my wonderful script from last week (touch the log, and test the directory path headache) was finally working. I can actually start looking at a new problem within some other file. Any file. Maybe calib again, so long as I don’t have to go near that block of code for a while. Why? Coding and patience are fragile things.

If that wonderful ssh connected terminal, happens to have a poor internet connection, well, you’re out of luck to debug the script as you test without serious lag. Frustrating but there’s workaround hacks like write the code offline, connect, run the test, look at the bugs, disconnect, repeat. Even better, right as the solution dangles itself to you to solve all problems once and for all, said internet connection DIES.

It’s like playing a game when Windows wants to restart for an update. Windows keeps minimizing your game right as you’re battling the big boss bad guy to bug you “Oh hey do you want to restart now or later for these updates to take effect?” No amount of patience will save you from the rage quit. Write down the genius solution. Take a day off. Pray to the campus dorm internet idols for a better connection & ping rate, then go at that sucker like there is no tomorrow. Code in anger. It gets the job done. Especially with enough lies, like if you finally get it working you never have to touch that code again.

Error between the Keyboard & Brain

My main task this week was to expand the calibration script with a simple task I’d done
before with a slight twist. First create a file using touch to hold a log in the directory for
a certain test, set up an if case because the user might want the log in a separate directory
and ask the user which they want to use. We’d rerun a few tests and then finally start
looking at some data. I had a few other tasks on top of this, but obviously I did not get
to those because programming can be deceptive. Once you feel grounded in another
language it can lead to a blind trust in the code you write. Hubris edging you on the
whole time, Pssh we’ve been using unix for two years now. We’ve used touch a thousand
times on the command line. So easy.

Instantly then when things go wrong we must distrust the new language! Dude no way
did I mess up my unix commands. It’s all perl’s fault! I’ve spend hours on the script, read
online tutorials finding no one else had problems doing this, reread the man page on
touch. It’s all stupid perl!

Except when perl isn’t at fault. And I realized this hours later. When my cutesy
workaround hack began turning into a contender for an obfuscated perl contest entry.
After shooting off an email to my professor that made me feel crummy. I obviously
sucked at coding for not solving this problem on my own. It’s so simple. Then the
response came and she asked if maybe the directory path wasn’t correct in my test inputs.
That reply almost made me ready to hide under my desk because that hinted at hours of
backing up mentally and rewriting the whole block of code to my original solution.

I would have loved to let myself get mad at that jerk of a user. All that time wasted! Bad
input was at fault! My code isn’t suppose to catch the user’s errors! But I was that bad
test user and I let those errors make me distrust the 80% working code. A little tweak to
get it 100% working was all it would take.

But really this stumble reminded me I’ve only been coding seriously for barely two
years. I’m still very much a toddler in terms of coding experience. This setback won’t
discourage me. Until this giant mess, I didn’t notice the huge improvements from my
first Programming I class to now. The important thing I need to keep reminding myself
is I need to keep writing consistently correct code over the long haul. That’s all that
is required. Not rushing myself because I should be handling more and writing harder
scripts. The code’s going to show that rushing by not working.

PERL me once, shame on you. PERL me twice, shame on me. PERL me thrice.....now that's nice!

English is certainly not the most spoken language in the world, being heavily overshadowed by Mandarin Chinese. But, it comes in at fair 2nd, spanning almost 400 million people across the globe. PERL on the other hand, probably comes in at a rigorously debated last place, or pretty darn close to it. One thing we can all agree on though is that a programming language whose intention was to create a seamless, convenient programming environment, still requires plenty of translation from one programmer to the next. In other words, the majority of my work the past 2 weeks centered around adapting old scripts in PERL to our newly created scripts via Stephanie's scripts and documenting accordingly.....that, and spending endless hours conjuring the perfect Halloween costume, which inevitably ended in me showcasing my inner nerd.


As the 2nd commandment of Stephanie's Undergraduate Research states, thou shalt have nothing to show for it more often than not. Fortunately, for my piece in the project, coding and documentation updates would be the upside to this, being immediately (for the most part) available and indicative of progress. But, we don't clock in/out while we're coding (We pretty much remain clocked in), so the time spent analyzing and coding certainly isn't accurately reflected enough in a small script that taunted you for hours on end. This was expected going in, for we are not naive knaves. On a positive note, however, the past 2 weeks were much more productive than the first week of learning PERL, given that I had something to build off of. The end reward of it all was a final tri-fecta of scripts that can read an input file of data taken from our 2 host computers, discard the trans fats, and give us what we want, the way we want it. Watch out Burger King!


Moving beyond our current work, with this being the mid-point in the semester, it seems fitting to take a look at how far we have progressed in the past 2 months. In reviewing Ben's (Last year's SSU CREU recipient) information from last year, being able to continue from where he left off seemed like quite the daunting task. Vaguely recalling him coming into our class to speak with Dr. Rivoire about scripts that had been running for 4 days straight did not perpetuate feelings of confidence, to say the least. To put it in perspective though, reading the articles about CPU/GPU analysis for our first week of CREU work didn't necessarily accomplish that either. And, to think that we are now doing exactly what I was not sure how we would even begin to tackle in the first place is evidence enough of progress. It has been quite the experience proving to myself that I could take on tasks that were totally benign to my previous Linux experience, as well as learn a completely new language without it being an available course here in the CS department - Quite the leap from sitting in the lab letting Lady Gaga pwn our computers. I've taken the logical approaches and confidence gained from the past 2 months and have applied them to my other classes/daily life. Heck, just by the nature of me being on campus more to work on CREU has subsequently ushered me into spending more time on other school work as well. And with that, I must bid you all adieu, but not without leaving the throngs of onlookers a taste of our PERL magnificence. Au revoir!



Our CPU (1 of 3 items we are currently analyzing) parsing script and output:

#!/usr/bin/perl

package test;

#Opens cpu data profile, spits out an error if it does not open.
open(FILE, "
#Reads in each line of the file one at a time.
foreach $line ()
{
#Splits the line into variables that we can use or trash.
($time, $ampm, $cputype, $c, $d, $e, $f, $g, $usage) = split(' ',$line);
($hr, $min, $sec) = split (":", $time);

#Checks to see if it is 12 in the morning, subtracts 12 if so (To reflect 24 hr time stamp)
if ($ampm eq "AM" && $hr eq "12")
{
$hr = $hr - 12;
}

#Checks to see if it is after 12PM, adds 12 if so (To reflect 24 hr time stamp)
if ($ampm eq "PM" && $hr ne "12")
{
$hr = $hr + 12;
}

#Checks to see if it is the first CPU being read, in order to print out 1 time stamp, rather than multiple of the same time stamp.
if ($cputype eq "0")
{
print $hr;
print ":";
print $min;
print ":";
print $sec;
print ",";
#Usage is the 100% minus the idle.
printf "%.2f", (100 - $usage);
}

elsif ($cputype eq "1")
{
print ",";
printf "%.2f", (100 - $usage);
}

elsif ($cputype eq "2")
{
print ",";
printf "%.2f", (100 - $usage);
}
elsif ($cputype eq "3")
{
print ",";
printf "%.2f", (100 - $usage);
print "\n";
}
else
{
}
}
}

Original File:
06:47:02 PM CPU %user %nice %system %iowait %steal %idle
06:47:03 PM all 0.50 0.00 1.01 0.00 0.00 98.49
06:47:03 PM 0 0.00 0.00 1.98 0.00 0.00 98.02
06:47:03 PM 1 0.00 0.00 1.00 0.00 0.00 99.00
06:47:03 PM 2 0.99 0.00 0.99 0.00 0.00 98.02
06:47:03 PM 3 1.04 0.00 0.00 0.00 0.00 98.96

06:47:03 PM CPU %user %nice %system %iowait %steal %idle
06:47:04 PM all 0.00 0.00 0.56 0.00 0.00 99.44
06:47:04 PM 0 0.00 0.00 1.00 0.00 0.00 99.00
06:47:04 PM 1 0.00 0.00 0.98 0.00 0.00 99.02
06:47:04 PM 2 0.00 0.00 0.00 0.00 0.00 100.00
06:47:04 PM 3 0.00 0.00 0.00 0.00 0.00 100.00


New Output File (5 out of 1000's of lines)

18:47:03,1.98,1.00,1.98,1.04
18:47:04,1.00,0.98,0.00,0.00
18:47:05,1.00,1.00,0.00,0.00
18:47:06,1.00,0.99,0.00,0.00
18:47:07,1.00,1.00,0.00,0.00

** This will be saved as a .csv file which can be read into Microsoft Excel and made very aesthetically pleasing!

BIOS, cpufreq, perl, sprinkles & cherries on top

The Undergraduate Research Commandments

by Stephanie Schmidt

1. Thou shalt do a lot of work.

2. Thou shalt have nothing to show for it more often than not.

3. Everyone in research shall pass through this phase.

4. Lie to thyself. Call it a phase even though thou shall know it will happen again.

5. And again.

6. And again.

When in the course of research, your allotment of tasks become disjointed from one another, remaining organized is crucial. Otherwise you won’t be able to avoid the problem of tasks falling through the cracks. This applies to groups of any size. As often as people stress this point, it’ll continually get blown off by fellow undergraduates as just one of those things seasoned professionals say to scare you. Er yeah...the folks brow beating this point, same ones who cry over bad documentation, once again have a valid point.

I promise for most schemes it’s not just busy work. Having the time to get through all the tasks per week is a different story entirely. Understanding the blog platform you are using is another good idea too, especially if posts go missing. Excuse this attempt to recapture the essence last week’s post covered. Debugging scripts, tweaking BIOS settings and learning the fun of redundant work sounds like an awesome week with so much progress made, eh? Quite.

Debugging should have its own class somehow in undergraduate requirements. I don’t care that people have their own method. Every debugging method boils down to the same handful of steps; what differs is the artistic way the steps are executed. Debugging a big file you didn’t write is scary. Especially when you’re a total n00b at the language. Just those ten lines I used to expanded a function brought with it a whole heap of warnings and bugs thrown up on the formerly working-ish program. Good documentation and cout statements were pretty much all that saved my sanity. Google is a great tool until you don’t know how to properly phase the bug in general terms.

The frustration iceberg was trying to find a compromise between perl variable syntax and command line expressions. Working around that one turned into hours of creative reworking to avoid any need for awk. Changing $1 to /$1 may be great for telling perl to not touch that variable. The command line, however, looking at that fix will act five year old being asked what is the square root of negative three. Failing silently is the worst problem a debugging entails. Wait, spending hours elbow deep in Google trying to figure out why an entire command line isn’t being grabbed only to learn oh...it’s not actually the code you wrote. Someone else’s piece is acting weird. Good documentation folks: not just a lame requirement but a means to cutting that debug phase in half if you can rule out bugs coming from pre-existing code.

A result of all this real world style programming has been a major change to my debugging method. I’ve started documenting outside of my code what steps I take to debug. It helps me revert on the fly back to old settings without bulk commenting out changes. Just because sometimes it won’t be your lines code that is causing the barf of bugs. Oh and updates? Don’t necessarily trust them, they can mess things up too. I’m looking at you Apple: ios4 has been a mistake to older generation devices.

Step back from the programming side of things. Appreciate how simplistically elegant the BIOS interface is for navigating. Getting into the BIOS itself can be an hour of frustrated restarts, mistimed keys & not hitting the correct key. Hint: it’s always delete. Except when its escape. Or when it’s F11. At least the restart button is universal. I give mad props to the BIOS interface though, because by enabling SpeedStep my data collecting life became easier. cpufreq actually started sending legit verbose data! cpufreq happens to be directly linked to a component within our benchmark software, which in turn is used when examining the collected data. Nothing important to hurry and get working you can imagine.

My tasks this week often had nothing, or very little, to show for themselves given how long they took to execute. Patience was key for jumping to the next task. Patience to integrate new information debugging brought and sucking up the pain of opening yet another instance of google or terminal. Patience is the hidden side to research. And lies. Lying to yourself that all that hard work gone unseen this weekend did something will be easier to accept under the lies of sprinkles & cherries on top.

We have toiled for 6 weeks, and alas......PERL

After an arduous 6 week battle with the benign concept of 'compatibility' our test machines simply did not want to accept, Stephanie and myself had seemingly finally made it to the point in our project that requires something we are familiar with: Coding. Such was not the case, however, as learning a new programming language, PERL, proved quite challenging.

One note of success this past week was coding in PERL to read a file, discard the junk, and output things in a much more organized fashion. Unfortunately, we were not able to make this work for my room, of which I was forced to manually clean. Some day.....

Aside from adding to my repertoire of French, Spanish, and C++, Stephanie and I also worked to expand upon Ben's GPU parsing scripts from last year, and also browsed through documentation to clean up and debug for our own future reference. We are confident that when we finish, our documentation will be PERLy clean.

Sudo 10 Degrees from the Sun

CUDA was not half the battle it promised to be with Ubuntu unlike Perf. I don’t know what Vince was talking about, rickroll loves Lady Gaga!

On to more serious notes, this week’s heat wave inspired in me a healthy respect for the unix command line. Something most undergrads don’t fully utilize until they’re higher up in their courses, at least for me. Naturally this is long after the useful commands have been forgotten. Google is only helpful when you know how to properly phrase the command query in question. The ability to utilize a system without a GUI should prove to be a good skill to have out in the workforce.

I think you’d be hard pressed to find any other research field that can be done from the comfort of home and still turn out meaningful results. Remote ssh’ing allowed the luxury working on rickroll without braving the triple digit heat to visit the setup in the basement. Two such commands that I learned to love for this portion of install, debug and then demanding the install has permission, were wget & sudo.

What throws up a permission error, sudo magically fixes.

(Image courtesy of xckd)

wget allowed for quick downloads directly onto rickroll exactly in the directory I happened to be in. If only they had this option in Windows, I’d never have to look for where a file downloaded again.

Now onto learning Perl & hopefully being able to understand it as well as document it. Who knew being trilingual would apply to programming languages?

Two Wrongs Don't Make a Right....What About Multiple Fails?

Good Morning CREU Fans! Looking back on the past week, it has certainly been filled with confusion, failure, mixed with downright frustration. In other words, it was a typical week in the life of programming and getting different components to get along! Our goals for the week were to install Ubuntu (A free-source operating system) on our 2 protege systems for the project, lolcat and rickroll, get them up to speed with CUDA (NVidia's Software to code algorithms to be executed via a GPU), make sure all of the necessary Linux packages were installed and running metric commands properly, and finally, update our fans. Sounds easy in theory, right?

The beginning of Stephanie and Dr. Rivoire's week was spent testing the 'try/fail' method for Ubuntu. Unfortunately, our systems were (seemingly) failing to install Ubuntu. The list of solutions:

1. New CD Drive - Fail
2. Changing install script command - Fail
3. Lots of Google to resolve the above - Fail
4. Burning the Ubuntu install discs are different speeds (8x, 16x, 24x) - Fail
5. Burning the Ubunut install discs in different formats (CD/DVD) - Fail
6. Update to Fedora 9.....updater was broken - Fail
7. Show that the software was actually failing to install by turning 'silent splash' off - Success!

At this point we even resorted to requesting software from Microsoft. We could see that the systems were still running post-blank screen, however. Roger, our server room extraordinaire at SSU, suggested to change the monitor after a few hours of fail.....and it worked! Who would've thought?

Unfortunately, our frustration did not end here. The install script was showing up fine on the new monitors, and went seemingly flawless, but Lady Gaga came on our resident radio and the screen went blank, again. Fail? Not quite. After a few more hours of tooling around, it turned out that the Ubuntu was installing successfully, but not informing us of this. Needless to say, we left Ubuntu feedback on their forum immediately.

Following our first step of success, we still have a large amount of work to complete for the week, and the success/fail pattern continued. Dr. Rivoire assisted in getting the rest of the Ubuntu/Linux partnership smoothed out, and installing some of the packages required to run our tests.

At the end of it all, we sat at our allotted time for the week still with some friendships to work out between CUDA, Ubuntu, and Linux. Two wrongs don't make a right, but we certainly have proven the trial/error theory. Cheers to more updates this week as we hopefully get our systems up and analyzing!

Week 2 - What's Your Version?

Learning about commenting code changes to avoid confusion when working in a group sounds like something along the lines of common sense. No one can agree what constitutes common sense so this week, in addition to learning more about the hardware setup, involved reading the user’s manual to the version control software used to manage the version control on our code. The best part of this software, Subversion, is that it requires any user committing a change to the master code must comment what they did e.g. “function foo has been entirely gutted and reworked” to be tagged with the version number. Thanks CREU for giving me something new to put on my resume.

Looking over the state of our hardware being used for testing involved the decision to save headaches now or later on in the research. Naturally we opted to save headaches now rather than down the line by committing to changes in the operating system setup. Instead of remaining with an older flavor of Linux, Fedora, we’re changing to a newer flavor, Ubuntu to better utilize a program that will give us access to more detailed information about the CPU.

GPUs: Your Personal Aesthetics Ambassadors

Sunpyo Hong and Hyesoon Kim focus their article upon energy conservation in GPUs by analyzing the optimal number of active cores vs. power consumption. Most people would probably muster an uninformed guess that power consumption for GPUs (or any computer model, for that matter) increases and decreases on a linear scale. In other words, one might assume the best ratio of power consumption and performance would be during a “power off” or idle state, or at max consumption/capacity. Unfortunately, such is not the case, and Hung/Kim can, by pinpointing the optimal active cores, “save up to 22.09% of run-time GPU energy consumption and on average 10.99% of that for the five memory bandwidth-limited benchmarks.” To do so, they obtain power model parameters to stress the different component of the GPU's architecture. Modeling different areas such as temperature and consumption by analyzing different inputs such as memory, they create an IPP (Integrated Power and Performance) Model, which indicates the performance and energy consumption of different components. Based on run-time statistics and graphs, the IPP predicts GPU power consumption, as well as the previously mentioned optimal active running cores, and performance per watt. As a result, the findings in this article and the proposed IPP can be used to optimize configurations for programs to effectively (and efficiently) use GPUs in the most productive/conservative ratios.

Sunpyo Hong, Hyesoon Kim, "An integrated GPU power and performance model", ISCA 2010.

---

Prior to GPUs being a hot topic for power consumption in computers, extensive research was done on CPU power consumption. The majority of what I learned through this article was really the basic, systematic approach to a proper power model and the components that comprise that model. Some of these rules of thumb include accuracy, generality, speed, and expense. The authors used 5 different systems, all of varying degree in power/performance potential, along with various modeling tools, to evaluate each system. From these models, a noteworthy item I came across was that the disk benchmarking for ClamAV was the most accurate because of the minor power consumption contribution disks have vs. CPUs. I considered it noteworthy because the article later mentions that there is a lack of insight into disk and memory power consumption even though CPU power consumption is decreasing, which is limiting the accuracy of benchmarking memory/disk intensive systems (Pg. 4). Our leader for the CREU project, Dr. Rivoire, also mentioned to us this week that with models that aimed to stress the disk's power consumption (while running ClamAV), there was a large variation in power consumption as opposed to the small variation on a normal system, and the subsequent results were anything but accurate; which brings the idea of ClamAV being the "most accurate" analysis method of disk power consumption into question. I also found it interesting, and would be curious to see, how the cooling system of a GPU might be factored into the equation, which is mentioned under the conclusion section. It is such because the cooling system would also consume power, and it would be interesting to see the complexity of the code that would go into making sure that component is reported to the OS (as also stated in the conclusion).

Suzanne Rivoire, Parthasarathy Ranganathan, Christos Kozyrakis. A Comparison of High-Level Full-System Power Models. Hotpower, 2008.

------

It was interesting to compare this article with having experienced growing up in the 90's and early 21^st century. PC gaming, software development, and GPUs in general developed an incredible amount over about a decade, and it is amazing to see where everything lies now after this article highlights a few of these points. One thing that was clarified for me was that I had a vague idea of the software/GPU relationship, naturally, because of gaming. But, I didn't necessarily grasp it as much as I do now after having read the article. And, although the concept of a GPU seems quite complex now as a CPU did 10-15 years ago for the average person, I believe that the knowledge (and expectation) of GPU specifications is only going to become mainstream once software is streamlined to take full advantage of them. The article mentions at the end that if you're “Twittering or checking email, GPGPU computing is not for you”, but I must disagree, in part. In due time, people will expect the same technology and graphics of a Playstation 3 or high-end Nvidia graphics processor to be emulated on their daily use PC, or better yet, their cellular phone - Budge even the slightest and the request for more will be even greater.

Matt Buchanan. Giz Explains: GPGPU Computing, and Why It'll Melt Your Face Off

URL: http://gizmodo.com/5252545/giz-explains-gpgpu-computing-and-why-itll-melt-your-face-off

---

As mentioned in the introduction, chapter 5 discusses power conservation on a small component scale, all the way up to conservation challenges of warehouse scale computers (WSCs). The first term analyzed is PUE; power usage effectiveness, which compared the IT power to total building power for a WSC. Several factors contribute to PUE, the majority of which would be the IT equipment and the cooling systems for the IT equipment (About 60-65% combined on average – Figure 5.2). One of the interesting things about the centers that have a good consumption ratio (under 2:1), interestingly enough, is because of non-computer related improvements such as air flow efficiency around the cooling systems and power conversion loss reductions. It was also interesting to note that with multiple components of any given data center, idleness is discouraged by spreading a small system load across multiple components (and vice-versa with large loads) rather than on one or a few, because it conserves more energy. This is true because a system will consume energy even on idle, but the increase of consumption with a light load is minor, making it a more efficient use to utilize multiple systems rather than a single system. The disk alone of a system can spend as much as 70% of it's energy alone keeping the hard drive platters spinning (Pg. 71). As I noted previously regarding technological improvements with GPUs, computing speed itself is nearly doubling at a rate of every 18 months, while maintaining the same power ratio. The article mentions that disk and DRAM are not on pace, however, and that future (well) balanced systems may become storage dominated, which will only increase the inefficiency of most of the world's already poor WSCs. The possible, some being quite easy to implement, solutions seem to be well within grasp, however, and it should be interesting to see if companies follow in the foot steps of others (such as Google) and the growing demand for energy conservation.

Chapter 5 from "The Datacenter as a Computer An Introduction to the design of Warehouse-Scale Machines". Synthesis Series on Computer Architecture, Morgan & Claypool Publishers, May 2009.

Week 1 - CPUs, GPUs, Power Modeling Oh My

I knew before this project that GPUs lived to make graphic heavy games like Left 4 Dead and Halo look awesome. I never bothered myself to learn the how behind crunching the instructions so quickly. The speed is achievable due to the multiple processing units inside the hardware. The cores are beneficial here unlike the CPU because the mathematics involved with graphics are a good fit for parallel programming [1]. Sanford Russell of Nvidia gives a lay friendly example looking at the traditional CPU & GPU roles in computing [1]:

If you were looking for a word in a book, and handed the task to a CPU, it would start at page 1 and read it all the way to the end … It would be fast, but would take time because it has to go in order. A GPU … "would tear [the book] into a thousand pieces" and read it all at the same time.

Industry is showing a surprising openness with one another by supporting OpenCL (Open Computing Language) as the standard across different GPU hardware. nVidia did come out with the first proprietary GPU programming model with CUDA. The idea of taking advantage of the speedup GPU computing gives has become recognized enough that Mac OS X Snow Leopard incorporated OpenCL.

[1] Matt Buchanan. Giz Explains: GPGPU Computing, and Why It'll Melt Your Face Off. Gizmodo.com, May 2009.

---

Unlike the language side of parallel programming there hasn't been an industry standard defining how to test/measure the total power of this improved hardware. Some attempts have been made with the Green Grid’s Datacenter Performance Efficiency (DCPE). The DCPE is normally incorporated within a simplistic formula [1]

PUE is defined as Power Usage Effectiveness i.e. the datacenter building infrastructure vs the actual equipment (like servers). PUE measurements are performed by electrical equipment without any disruption to normal operations. Great if a datacenter is not available for benchmarking. SPUE stands for Server PUE a ratio of total server input power vs power consumed by components like motherboards, CPUs, etc. But there is no protocol for measuring SPUE. The actual power a server draws could be erratic depending on the activity. Introduce another set of numbers to consider, benchmarks measuring energy efficiency of the servers: Joulesort and SPECpower_ssj2008 benchmark [2]. Both benchmarks attempt to isolate efficiency differences in the hardware.

[1] Luiz André Barroso and Urs Hölzle. Chapter 5 The Datacenter as a Computer An Introduction to the design of Warehouse-Scale Machines. Synthesis Series on Computer Architecture, Morgan & Claypool Publishers, May 2009.

[2] In the interest of fair disclosure our faculty advisor, Dr. Rivoire, is also involved in the team behind JouleSort.

---

The two popular methods on real time power modeling are detailed analytical power models or high-level blackbox models. For a blackbox model the OS-reports make up a large component of present power modeling & benchmarking schemes. This has been the standard as an accurate look at the system under the assumption that CPU, memory, and disk are the main draws of power [1]. In other words graphics processors or power-aware networking equipment fall in the cracks under this assumption bound testing. To learn a great deal about one component though the analytical power model is superior to a blackbox model. An analytical power models looks only at a single component within a system. Extrapolating a model to include an entire system would be impractical and unfeasible. Hardware is moving away from CPU-dominated increasing the outdating of these models to paint an accurate picture.

Only recently have detailed analytical power models or high-level blackbox models have been attempted for modeling GPU power consumption [2]. Ma et all found with more work being sent to the GPU there is a noticeable demand in not only higher power consumption requirement but an increase in cooling solutions (also increasing the power consumption). A current problem with testing GPU Ma et all found is the potential power consumption to rapidly spike (high or low) during testing [2] exceeding the modeling parameters. Given the varying nature within GPU hardware compared to CPU, setting the boundaries for the parameters of a model, as Ma et all found, may require differing models depending on the benchmark being run.

[1] Suzanne Rivoire, Parthasarathy Ranganathan, Christos Kozyrakis. A Comparison of High-Level Full-System Power Models. Hotpower, 2008.

[2] Xiaohan Ma, Mian Dong, Lin Zhong, Zhigang Deng. Statistical Power Consumption Analysis and Modeling for GPU-based Computing. Hotpower, 2009.

Welcome!

We'll use this blog to post weekly updates on our 2010-2011 CREU project.  You can visit the main project page to see what it's all about.