Skip to main content

SenSys 2009, Day One

I'm here in Berkeley for SenSys 2009, the premier venue on sensor network systems. There are 21 papers in the conference this year (out of about 120 submissions) and the quality of the papers is very high. The proceedings have been posted online here. I happen to be the program co-chair along with Jie Liu from MSR, so I feel compelled to blog about the conference.

This morning, Bill Weihl from Google gave the keynote presentation on "The Power of Energy Information." He talked about Google's PowerMeter system which allows consumers to track and visualize the power consumption in their homes -- potentially allowing people to learn about their patterns of electricity use and identify anomalies (like a broken air conditioner). Bill also talked about preliminary work at Google to shift power generation load through smart charging of plug-in electric vehicles, dynamically turning charging on and off across fleets of vehicles based on the grid's fluctuating capacity. It was a great talk and emphasized the potential for large-scale information on energy consumption.

A few highlights from some of my favorite talks today.

Om Gnawali from Stanford gave a talk on the Collection Tree Protocol, which is now the default routing protocol in TinyOS. CTP is the result of a substantial effort to increase robustness and reduce route maintenance overheads for large-scale spanning tree networks. Perhaps the best part of the paper is that they ran extensive measurements on about a dozen sensor network testbeds (including our own MoteLab testbed) to validate the protocol's performance. It is interesting to see the variation in performance across different settings.

Mike Liang from JHU gave a talk on RACNet, a sensor network designed to collect temperature and other data in large datacenters. Unlike "conventional" sensor networks, RACNet uses powered nodes (plugged into the USB port on a server rack) so the need to use, say, low-power MAC protocols is not a concern. RACNet focuses on a token-based data collection protocol to achieve high reliability across a range of node deployment densities, for networks with hundreds of nodes. This is an unusual setting for wireless sensor networks since one might imagine that it is trivial to have the servers themselves collect this data, but it's actually better to have a separate monitoring network that does not directly impact the servers.

Arvind Thiagarajan from MIT gave a talk on VTrack, which uses sparse localization data from mobile phones -- using a combination of GPS and WiFi localization -- to estimate travel time delays for individual road segments. This system provides high-resolution estimates of drive times through "crowdsourcing" mobile phone location data. This involves correcting noisy location estimates using an HMM to map trajectories to road segments. They evaluate the system on more than 800 hours of drive data from a fleet of taxicabs in Boston. I'm glad this paper made it into SenSys since it is not a paper about motes and TinyOS, and points the way towards future directions for the field.


Post a Comment

Popular posts from this blog

Why I'm leaving Harvard

The word is out that I have decided to resign my tenured faculty job at Harvard to remain at Google. Obviously this will be a big change in my career, and one that I have spent a tremendous amount of time mulling over the last few months.

Rather than let rumors spread about the reasons for my move, I think I should be pretty direct in explaining my thinking here.

I should say first of all that I'm not leaving because of any problems with Harvard. On the contrary, I love Harvard, and will miss it a lot. The computer science faculty are absolutely top-notch, and the students are the best a professor could ever hope to work with. It is a fantastic environment, very supportive, and full of great people. They were crazy enough to give me tenure, and I feel no small pang of guilt for leaving now. I joined Harvard because it offered the opportunity to make a big impact on a great department at an important school, and I have no regrets about my decision to go there eight years ago. But m…

Rewriting a large production system in Go

My team at Google is wrapping up an effort to rewrite a large production system (almost) entirely in Go. I say "almost" because one component of the system -- a library for transcoding between image formats -- works perfectly well in C++, so we decided to leave it as-is. But the rest of the system is 100% Go, not just wrappers to existing modules in C++ or another language. It's been a fun experience and I thought I'd share some lessons learned.

Why rewrite?

The first question we must answer is why we considered a rewrite in the first place. When we started this project, we adopted an existing C++ based system, which had been developed over the course of a couple of years by two of our sister teams at Google. It's a good system and does its job remarkably well. However, it has been used in several different projects with vastly different goals, leading to a nontrivial accretion of cruft. Over time, it became apparent that for us to continue to innovate rapidly wo…

Running a software team at Google

I'm often asked what my job is like at Google since I left academia. I guess going from tenured professor to software engineer sounds like a big step down. Job titles aside, I'm much happier and more productive in my new role than I was in the 8 years at Harvard, though there are actually a lot of similarities between being a professor and running a software team.

I lead a team at Google's Seattle office which is responsible for a range of projects in the mobile web performance area (for more background on my team's work see my earlier blog post on the topic). One of our projects is the recently-announced data compression proxy support in Chrome Mobile. We also work on the PageSpeed suite of technologies, specifically focusing on mobile web optimization, as well as a bunch of other cool stuff that I can't talk about just yet.

My official job title is just "software engineer," which is the most common (and coveted) role at Google. (I say "coveted&quo…