Progress Summary

Our project's model is currently trained on models where the CPU is the main consumer of dynamic power. Results are fragmented between the two test machines, lolcat and rickroll, due to data collection errors. The next steps planned are finishing data collection, examining GPU benchmarks possibly with the added benefit of instrumenting the GPU, and analyzing oddness within the results.

For FDTD3D (GPU benchmark) rickroll’s MSE, rMSE/mean and DRE display a delta in the results. The MSE at frequency 2000 is 4.13 and goes to 318.29 at frequency 2200.  DRE repeats this delta at the two frequencies moving from 0.10 to 0.63.  Root MSE/Mean’s 2000 to 2200 frequency delta is a change from 0.01 to 0.12. A reasonable explanation would be to hypothesize that before 2200 the CPU is bound. Other data presently does not support this explanation.

Using two benchmarks, nbody and binomialOptions, as sets of train and test  (same model both train and test, using nbody as train but binomialOption as test and vise versa) lolcat’s results stress how unaware the model is of the GPU’s influence on the expected power (but the power does correlate well to CPU & disk for this workload). The model cannot predict a reasonable expected power when the GPU is stressed in addition to the CPU, or the GPU is stressed but not the CPU.

Once calibration data recollection on locat finishes and is analyzed for errors, the next step will be proceeding on GPU awareness. For more insight on the GPU’s role with power consumption NVIDIA-smi will be implemented for GPU instrumentation.  The model can’t predict beyond the CPU exercising at 100% but if a GPU aware component is added the prediction should be less erroneous.

Resolving a Heisenbug

Resolving a Heisenbug can be tricky since by its nature it resists the debugger. Instead we decided to go the unscientific way of throwing a bunch of solutions at the problem, then in true programmer fashion not questioning what fixed Wattsup. 

Part one of the solution was to rewrite the packet handling code within wattsup to fix several line errors and how wattsup was handling mis-sized packets. Originally the code would give up and kill the run if the packet size (packets being what the watts data was sent inside) changed due to the program falling out of sync. Now Wattsup recaptures the mis-sized packet and concatenates it with the following packet (which for the majority of the time will also be mis-sized and follow the first packet in data order).

Part two involved unplugging the meters for a while to clear their caches. While unplugging the meters we checked just in case the physical meters were over heating. One meter did feel warm to the touch which could be a result of overheating or normal heat left over from finishing a workload. A last minute idea when we went back to reconnect all the cables included switching the meters measuring each computers. In addition the work space was also rearranged to provide more air flow around the meters since they previously felt warm to the touch.


Wattsup now runs without problems! What actually fixed the Heisenbug? Probably a combination of all three solutions (rewriting code, switching meters and increasing air circulation). The important question now move toward analyzing all the data that we have finished collecting.

Here are a few graphs from our data that will inspire the future headaches from analysis:

Heisenbug and Martha Stewart Cleaning

Bottle necks are incredibly frustrating, they hamper progress because the research can go only as fast as the slowest component. If the slowest component has intermittent bugs then that pace is a frustrating crawl. At long last the bottle neck on this research is software no one involved on the project wrote! That shouldn't be cause for celebration, but as childish as it sounds, it's nice for once to not have the blame be on the research team.

There's even a name for the type of bug causing our bottle neck:

Heisenbug - A bug that disappears or alters its behavior when one attempts to probe or isolate it ... the use of a debugger sometimes alters a program's operating environment significantly enough that buggy code ... behaves quite differently.

Turn the debugger on, the problem vanishes. Turn the debugger off, problems resurface but we can't recreate the error with the debugger back on. This is incredibly frustrating to realize, try to debug and work around.

Sadly it is our data collection software, Wattsup, that is the one dealing with said Heisenbug. The research uses Wattsup to take a reading of the power (in watts) at a set time interval during the length of the benchmark run. The logs show a normal run. The error logs only have one error that appears randomly during the course of a run. But look inside the .ac file (where a timestamp and a measure of watts at that time are expected) and lo, three to four minutes before the end of the run the data cuts off.

What does one do while isolating Heisenbugs? You have let the run go and tail the logs but these runs go from twenty minutes to hours. Can't sit there hitting ls -l on the logs. Instead it's the perfect time to go Martha Stewart spring cleaning on all the versions of research code between rickroll and lolcat. Basically clean up the update logs, output and naming conventions from automatically generated files. No more should we need a nifty flow chart.

Organization and version control are crucial! Actually executing organization and version control however involves hoping between multiple languages. Unix, perl, python, and some regular expressions made life easy while the brain began to feel the differences in syntax. Hopefully from this point onward (once Wattsup is "debugged" for good) the project can get some solid data from lolcat. Then onwards to find fresh headaches analyzing our model against actual data from rickroll and lolcat.

The Wonder of More Time

Not even a week back at the research and the progress is unbelievable! What could possibly be the reason behind so much happening in only two days? Was it the short break away from the data? The new eight hours the research is getting each day? Who knows! I just hope the progress keeps running full tilt. Let's recap so far what's happened since coming back from the brief hiatus at the end of last semester and the parting of Vince.

Day 1 
Back at hitting the code actually turned into spring cleaning. In the mad dash of running ahead with the progress last semester....things got a little hairy in the directories. Test runs going everywhere and scripts written in haste proved they needed to be rewritten. So the first day back was spent cleaning up directories, sorting/rerunning data runs and patching mischievous scripts that needed dire documentation. It's amazing feeling the difference of having the time to not only spot errors but correct them right away. This compared to fighting for time to do research and homework and projects during the semester? I'll happily take my eight hour work day this summer over the last two crazy 10 hour a week semesters.

Day 2
Analyzing data has never been so interesting!  The day began with basically filling out a very fancy excel sheet and utilizing functions in R. This was all done on data from our calibration, CPU and GPU benchmarks for Rickroll. With more initial data to go on than previously, two things jumped out:

1) Our GPU numbers for mean squared error and dynamic range error are curiously opposite of what we initially predicted (for certain frequencies the numbers are inversed: we expected higher numbers at lower frequencies and lower numbers at higher frequencies).

2)Due to the behavior of how specJBB stresses the CPU and what happens with the power consumption, there is serious discussion of adding another CPU benchmark to really stress the CPU further.

I can only imagine how much further we'll be at the end of this week.

Brief Hiatus but Not Senioritis

While Vince will be leaving the project I'll be staying on for the summer (sadly not graduating until next semester). After a brief hiatus to marathon through finals I'll be resuming work on the project for the summer. This time however besides a change in personnel there will also be a change with me moving from part time (10 hours week) to full time (40 hours per week) which will be an exciting way to experience at how graduate students conduct their research.


Tentative result from one of the machines used to record measurements show not a lot of difference predicting FDTD3d power vs. specjbb (two benchmarks being used to stress the power consumption of the GPU and CPU's). If these results hold for the next sets of analysis on most/all frequencies I'll look at potentially installing some more GPU and CPU-intensive benchmarks. Adding benchmarks could help aid the understanding what about the model is good and bad at in more detail.


In addition to analysis, more data collecting and benchmark experimentation I'll also be looking to improve some of the existing code. A busy summer indeed!

Morrow, out!

Ok, so the Seacrest reference is terrible in of itself, but it is bitter sweet because this particular blog post will also be my last.

It has been a long year of working towards modeling GPU power consumption, and just as the last week of semester gives way, leaving 9 days before Stephanie and I graduate, we are at the cusp of accomplishing our goal. At times I've wished that French was as easy as coding in PERL, but when I realized that sometimes PERL and the running of our benchmarks come up with things missing out of the blue, and 'fix' themselves after cutting/pasting the same exact code into the script only to have it magically work, I reconsider the ramifications of such a request.

This past week and a half Stephanie has been running the NVidia GPU benchmarks (FDTD3d), stressing the GPU with basic graphics runs, in order to gather data about the power usage of the GPU. In doing so, this kicks out .csv (commea separated values) files that are accessible via Microsoft Excel, as well as R (statistics program), that we can then manipulate and create models with. Creating these models basically tells us that the reading of the GPU power consumption is horrendously inaccurate (as expected), and creates another goal to strive towards - Creating (somewhat) accurate models of GPU power consumption. This will be the goal that Stephanie works towards over the summer.

As for myself? I shall be traveling to my home state of Arizona from the end of July through the middle of September to work a wine harvest (Wine in Arizona...?) in Sonoita, AZ, and then travel back to Rutherford, CA to work another wine harvest until December. After that, the plan is New Zealand or Australia, and then the wine pinnacle of the world, France. How this all relates to CREU? Being involved with CREU has helped me gain the confidence of learning a new way of perspective and thinking (via PERL), as well as the discipline and motivation to learn said language on my own - We didn't take any classes or training courses for it. Because of this experience, I've also gained more confidence in tackling other tasks, such as that of learning French and blending the use of it into my career path; marketing, wine, and computers. Quel bien (How nice) !

It has been a wonderful experience my last year in college, and we certainly couldn't have done reached our goal without the support of CREU, our advisor, Dr. Rivoire, and our hordes and throngs of fans. It has been a pleasure - Thank you and au revoir!

Dude Where's My Data?

Coming down from the high of industry talks, vacationing and socializing with the family, it was back to the binary trenches. Because errors and code bugs never rest!

Parting of using scripts to automate the data retrieval aspect from the benchmarks so we can run them in successive order across controlled frequencies is that when things go wrong...they go missing. No more non-compiling code or segfaults just missing records that aren't apparent even when stalking the logs real time! Recently our error logs were deceptively empty because the data logs were empty as well. The power meter (delightfully from a brand called WattsUp) was fine. Maybe the cable was shorting out? Back to running baseline tests we resolved that the meter hiccuped and settled down to running the few troublesome frequencies one at a time instead of a set. This resolved the problem and began a new one.

Reading is not hard but for some reason it's deceptive when sleep deprived. When the time came to run the benchmarks related to the GPU (as apposed to the troublesome CPU). Well, that didn't run so smoothly either as does any plan when it meets contact with the enemy on the field. Forgetting to rename the tests surprisingly did not harm anything because the test failed after one frequency and only destroyed an otherwise very small dataset that can easily be recovered.