Skip to main content

SenSys 2009, Day Three

Today's the last day of SenSys 2009. Some pictures from the poster and demo session are up on the CITRIS website.

The morning session on time synchronization features one of the award papers -- Low-power clock synchronization using electromagnetic energy radiating from AC power lines. This is a very well-executed paper that leverages specialized hardware to pick up the magnetic field radiating from AC power lines to establish a common 60 Hz clock source for a set of sensor nodes. Nodes measure a common frequency but experience local phase offsets, which are corrected for using message exchanges. The hardware only consumes 58uW so this is a very practical approach. If this hardware were widely available, this could be the last word on time synchronization, at least in settings where nodes are deployed in the vicinity of (not necessarily plugged into!) AC power - including buried and overhead power lines.

Shuo Guo from University of Minnesota gave a talk on FIND: Faulty Node Detection for Wireless Sensor Networks. The idea is to look at differences in the ranking between nodes' sensor data and the estimated physical distance from a target to detect sensor faults. This assumes that there is a monotonic relationship between distance to a target and a node's sensor reading. The paper seems to consider a fairly narrow definition of a "fault" and I'm not sure how well this maps onto the kinds of faults seen in real world deployments, nor how this would relate to Byzantine faults caused by buggy or malicious code.

Jung Il Choi from Stanford gave a talk about a network protocol isolation layer, to enable multiple protocols (e.g., CTP and Drip) to coexist without stomping on each other. The isolation layer allows multiple protocols to share a radio link fairly, and observe the same LDR when other protocols are active. This is accomplished using a grant-to-send mechanism that bounds the times when protocols can transmit (to avoid self-interference) and fair queueing. This strikes me as being quite similar to Balakrishnan's Congestion Manager, though without explicit feedback to applications.

Overall the conference was great this year, and the venue worked very well to keep the audience engaged. At the same time it is a huge relief to have it all wrapped up. Looking forward to SenSys 2010 in Zurich!

Comments

  1. Hey Matt-

    I don't think I heard anything about SenSys 2009 attendance; how did it compare with previous years?

    ReplyDelete
  2. I'm pretty sure it was upwards of 230-240, which is at least as high as previous years - I recall Tarek saying it is typically about 200.

    ReplyDelete

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…