Recently I’ve been away at a couple of conferences. I presented a (terrible) poster about information flow at ASPLOS/VEE in Washington D.C. a couple weeks back (Mar 9–13). Then I spent finals week back home creating a new (and much improved) poster, which was presented at CGO in Seattle, WA. Though, the CGO trip wasn’t as appropriate to the work, and didn’t result in any useful social networking (the primary point of conferences). The poster was of much better quality, not only because of the additional time spent creating it, but also because of the lessons learned from the first poster session.

Though I think that a whole week spent creating a poster is a bit much, the end result was probably worth it. Everyone in lab spent most of that week creating a poster for each of our separate projects. We were able to give each other feedback that led to improved revisions. I, personally benefited greatly from looking at the posters that other had made, and incorporating (copying) presentation features that I liked into my own work, features that I would have been hard pressed to create on my own (I am not a graphic artist). In the end, we have each created an explanatory device that can be used to advertise our work to visitors for the next year.

I noticed also that the review process works for presentations as well as posters. By practicing a few times in front of the group, I witnessed improvement in others. Though, it’s a hard blow to one’s ego to be critiqued at the end of, or during, a presentation; it’s worth it. The slides, the talk, the content, and the delivery all improve. I personally dislike going through the process, but the end results are fulfilling in their own way. I felt much better about my poster at CGO than I did at ASPLOS.

Also, the best researchers are able communicators. That takes practice to develop and critique to hone.

I did an earlier post about finding a decentralized solution to the Cascade Failure problem. I was fortunate enough to explore this topic a bit more in depth by proposing it as my term project for the Distributed Systems class. It took between two and three weeks of work to write a paper and hack together a small simulator to test out some of my ideas.

Since this marks my first attempt at a paper, and I think the results came out rather weak, I’ll make some brief comments about the process. Because it was a class paper, I spent substantial space and time condensing the other papers on the topic. Studies on the topic are quite sparse, there were really only four such papers, all published later than 2000. So about half of my paper is devoted to repeating their models and observations, followed by an all-too-brief comparative analysis.

The next section introduces some arguments about why the decentralized approach might be doomed to failure. I actually set out with the complete opposite goal, I wanted to find a solution to the problem. But, after many shot-in-the-dark attempts at finding one, I went after an impossibility proof instead. It isn’t what I would really call a rigorous proof though, it’s much more intuitive and informal. But I hadn’t seen the argument made in any other papers, so if I claim a small contribution to the field, this would have to be it.

I actually did follow up the proof, with a section on the methodology for my simulation. I think I was much more detailed about the setup than any of the other researchers were about theirs. I tried, and failed, to repeat the observations of others; so I can’t claim any guarantees about the accuracy of my model and simulation. I tested several off-the-cuff first-shot attempts at what protocols might help alleviate or stall a cascade, with spectacularly poor results. Every protocol I tried was worse than doing nothing! In fact, far worse than doing nothing! Worse by a factor of 50–200! So after all that work, I just figured out some stuff that doesn’t solve the problem, and had to explain why.

I think the best part, though, is the suggestions for Future Work. I’ll probably always enjoy writing this part, because it’s nearly impossible for me to get through my work without thinking of other ways to do stuff, or more things to try out.

Basically, it takes forever to write a paper. And as far as the sciences go, the paper really is really only the tip of the iceberg in terms of effort. It summarizes and represents a substantial amount of effort in data, simulation, code, research, analysis, etc…

My specific gripes about what could be made easier:
• LaTeX gives pretty results, and is the de-facto standard for scientific publication, but it’s kludgy, hard to use, and has a high learning curve.
• There’s no decent and easy graphing/charting programs. So, it’s best to invest time into learning one. I had to write python scripts to parse and reduce my data anyway, so I used matplotlib.
• And there’s no such thing as a vector drawing package that beats drawing sketches on napkins. So conventional artists have nothing to fear. It took hours to find, learn to use, and finally produce, a silly little, nearly superfluous, 7-node graph.
• Network/Graph visualization tools are also scarce, so I had to write my own, just to double check that the simulation behaved properly. I didn’t mention any of this kind of effort in the paper though.

Anyway, go ahead and have a look at my paper: Cascade Failure in Distributed Networks