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.

April Showers....Recapping an Insane Month

With Tapia, Midterms, and now Spring Break finally behind us we are digging in deep for the home stretch of the semester. As I prepare to graduate in less than 34 days, we are pushing to wrap up the bugs that have been keeping us from preparing a data set that includes not just the CPU models, but the GPU as well. We are aiming to have at least a few models to go off of in order to send Steph off into the summer program with a good foundation for increasing the accuracy of the GPU models.

Given that she was back home in Southern CA for the break, and I spent mine working and traveling the bay area, we are refreshed and ready to hit the ground running this week, even in the midst of finals and graduation coming up.

As far as the Tapia SF Conference was concerned, we had the wonderful opportunity to meet with our research adviser, as well as her adviser (our grandpa!) for coffee beforehand. Following that, over the course of 3 days, we attended symposiums on topics varying from robotic climate modeling in Antarctica, to 3D rendering and photo matching programs people can use to link their photos to specific street locations on Google Maps. Each day was non-stop from 8am to 10pm, and definitely filled with more information than we expected. All in all, it was an amazing experience that allowed us to network, make new friends, and solidify some of our goals for the future around computing.

With that being said, progress reports will be posted soon, hopefully with some new pretty data sets!

Half empty, or half full?

As we near the half way point of the semester, with the Tapia conference and spring break both right around the corner, it certainly is warranting of another moment to reflect on everything that we have done. This is especially true and fitting being that we are waiting on our GPU programs to become agreeable and new data sets to become available to analyze.

As I mentioned in my previous post we have achieved the milestone we essentially have been aiming for since the beginning of this research - Model the CPU, AC power, and Disk usage of a computer. In doing so, we have paved way for the preparation of (attempting) modeling the GPU as well, on some recognizable, not so horrific data set. With exactly 2 months until commencement, the time is ticking on producing said models. But, we are confident that we will do so by then.

To expand upon that, our goal right now is to have these readily available by the beginning of spring break (April 18th), in order to be able to improve upon these models when we return the following week. Theoretically, if we are able to do so, we will have surpassed the previous gains from last year's SSU CREU research. Eventually, we will hopefully discover better ways to model GPU power consumption and make, if even slightly, a little more sense of a relatively unexplored topic. For now, unfortunately, we are at the mercy of NVIDIA's GPU programs and CUDA not quite agreeing the way NVIDIA would with more established OS's.

To be continued.... !