Dullroar

It's a funny thing about grad school: I'm being trained to do research, but nobody's ever made me read a book about it, or take a course about it. Nobody's even given me a definition of what it is. What I hear around seminars these days is debate about whether some piece of work is good or bad, but I hardly ever hear debate about whether or not it's research.

Maybe I should have a disclaimer on this post: I'm talking about my experience in computer science grad school doing systems research. I don't know what goes on in other disciplines (but I'd be really interested in finding out).

What I have noticed is that there are a number of "patterns" that research falls into. A research pattern isn't that far off from a software pattern, really. In both cases, the pattern is just a framework for thinking about a problem. Patterns alone aren't enough to solve problems, but I think they make it easier to see what's going on by making the reseach techniques more explicit.

Here's one research pattern that I've been seeing everywhere lately: Start with a problem that doesn't have a satisfactory solution. Understand the problem's constraints as fully as possible, and focus on how each constraint limits the range (and quality) of solutions. Here's the trick: find the constraint that's most restrictive and eliminate it (or just loosen it). This should make one sub-problem much easier, but it probably also creates several new sub-problems. Now work forward, solving all the sub-problems and arriving at a solution that's much better than the solution under the original constraints.

By the way, I'm not saying that good solutions involve assuming impossible things are possible. It might be a good idea to assume that an elephant can be supported by toothpicks, but the solution isn't complete until there's an explanation of how to do it.

I can accept that the easiest way to teach a person how to do research is to have them start researching. I just wish that when I started grad school, someone gave me a set of stories, or patterns, or something, explaining how research gets done. Sure you can read papers, but they're very focused on the final product, and they're more about what than how. So how about it? Shall we collect our research patterns somewhere?

Posted by Andy at 09:41 PM | Permalink

I've finally gotten the gumption and spare time together to release a tiny little logging library I've put together for formatting debugging messages and writing them to disk. It's called Quicklog, and it's aimed at C++ users on Linux.

What's so great about Quicklog? Its interface is very much like C++'s iostreams. If you can work with cout and cerr, you're already familiar with Quicklog's syntax. Many other logging packages use printf-style syntax, and working with that is just painful. My idea is that the easier it is to log, the more logging will be done, and then the easier it'll be to debug the system from the logs later.

Quicklog's other cool feature is that it's, ummm, quick. Especially on slower CPUs, the bottleneck in log writing is converting all those integers and floating point values into ascii representations. I fixed that by splitting the logging task: at runtime, ints and floats get written to disk in binary format, and then later, there's a postprocessing step to translate the binary numbers back to human-readable format. This split reduces logging overhead by about 80% for the workloads I've been using.

You can download Quicklog here. I hope that someone will find it useful, even though it lacks a bunch of features right now.

By the way, Quicklog has no relation to Quickdog, which was a dotcom startup. In the interest of full disclosure, I should say that my old company, 61C Networks, bought Quickdog's LCD projector when Quickdog went bankrupt. Therefore, I'm dedicating this first release to that LCD projector, which was acquired by yet another company after 61C's assets were liquidated.

Posted by Andy at 06:55 PM | Permalink

Two Cisco VPs from different divisions gave talks at CMU today. Cisco wuvs us!

Posted by Andy at 03:57 PM | Permalink

In February, I wrote about choosing simple problems to solve since they're hard enough. But what I didn't know was how to find the research challenges. Someone would suggest a problem, and I'd take a look, see the obvious solution, and conclude there was no research to be done there.

Today, as I draw closer to having a dissertation topic (or else quitting the program to start an enterprise network security company), I've started seeing the hard parts, what some network researchers call the "impedance mismatches" (because we network researchers are all descended from electrical engineers, but we've long since forgotten what any of that electronics stuff is about, we grab random terms from electrical engineering and use them improperly). The key is that I've finally internalized an idea of what it must be like to operate a network. Let me make this maximally cheesy for emphasis: Walking a mile in the user's shoes, getting to know how he really solves problems with the tools at his disposal, has helped me see why simple problems aren't so simple.

I've been trying to understand how a network operator deals with things like assigning machines to VLANs in an ethernet network. How does the operator decide where a PC belongs? It could be based on the physical port where the PC is plugged in ("Ah, this new PC is connected from the engineering wing, so it must belong in the engineering VLAN."). It could be based on the PC's ethernet address. It could even be based on which user has logged into the machine. Making all of these a reality is ostensibly simple, but the problems arise in the details. For instance, that idea of assigning a VLAN based on the user: this means the machine needs to be in a VLAN (to get an IP address) for the user to authenticate to the network, but the proper VLAN for the machine can only be determined after the user authenticates. Just an odd little thing, really, but suddenly my simple problem has some depth.

Two caveats. First, there's a point in all this where I have to step back and say "yes, that's hard, but is that how someone really wants to solve the problem?" And often, the answer is simply "no." It's rarely the case that an operator wants to assign machines to VLANs based only on the user logging in. But that's ok -- it's just time to look for another odd thing to worry about. And the second caveat is that I still don't have a dissertation topic, so I'll have to let you know how all of this really turns out in the end. And finally, I admit, I didn't tell you how I internalized the experience of being a network operator. I don't really know, but I used to watch Pretender a lot.

Posted by Andy at 11:38 AM | Permalink

As a researcher, I'm constantly looking for a non-trivial problem to solve. It's got to look really difficult, and it's got to be the right "type" of difficult (I'm not going to come up with a quicker quicksort, for instance). It's obvious that solving a difficult problem takes hard work and a lot of thought, so one of the most challenging parts of working on a hard problem is knowing when to throw in the towel and move on.

What I just realized (after my advisor pretty much pointed it out to me) is that it's just as important to find a seemingly trivial problem and ponder why it isn't trivial. This is not the same as taking a trivial problem and adding extraneous constraints to it until it's no longer trivial. Rather, it's more about taking a problem and delving into the details of the solution.

I'm going to see how far I can push this. From now on, I'm only going to tackle the easy problems.

Posted by Andy at 10:37 AM | Permalink