Last year's enrollment for CS 124 was 53. So far, current enrollment for this year: 119.
I imagine a few are still just taking a look and might drop. But a doubling is looking possible.
This would be the largest CS 124 class since I started teaching it in 1999.
Saturday, January 28, 2012
Thursday, January 26, 2012
Faculty Applications
An anonymous commenter asked how we evaluate faculty applications. While it's a little late, it's a valid question, so here are some high-level thoughts. Here I'm speaking only for myself, of course.
First, I should point out that ideally, we're not reading your application from scratch -- we already know you. We've seen you give a talk we like, or enjoyed one of your papers, or otherwise formed a (positive) impression. The most important things you can do when applying come well before you write up your application. If you're not taking advantage of opportunities to make yourself known in the community as a graduate student, you're not doing your job. [Obviously, we don't only look at applications of people we already know. But that just makes our job harder, and makes it harder for you to get picked out of the crowd.]
After that, it's not exactly rocket science. I'm looking for a strong record, and the first things I'm looking for are good publications and good letters. Applicants on the first pass are usually sorted into 3 basic categories: invite for an interview, decline, or study further. The publications and letters are the best guide for what pile you'll go into.
Once the pack is cut down, more details will come into play. Some of us will probably read your papers to get a better idea your work. Natural more detailed questions come up: How interesting is your work? How well do you fit our department needs? What teaching experience do you have? Is Harvard a place where we think you would be successful? (For example, what other areas of Harvard might serve as possible points of collaboration?)
The interview helps us answer these questions further. At the end of the day, what we're deciding is if we want you as a member of our department. Research quality is a primary issue, and usually the primary issue. But at this point, hopefully all of the people we're looking at have high-quality research records, with results that we collectively find compelling. So the secondary issues I mentioned -- are you a good fit for us, are we a good fit for you? -- do matter.
In the end, I don't think there's too much you can do to "strategize" your application -- because the main issues are to have a good work record, get people who can write you good letters, and be an interesting person who seems like they'd make a good colleague. I expect that's not surprising anyone. Though I'm sure since I wrote this a bit hurriedly, someone will point out where I've not described things suitably carefully or in enough detail.
First, I should point out that ideally, we're not reading your application from scratch -- we already know you. We've seen you give a talk we like, or enjoyed one of your papers, or otherwise formed a (positive) impression. The most important things you can do when applying come well before you write up your application. If you're not taking advantage of opportunities to make yourself known in the community as a graduate student, you're not doing your job. [Obviously, we don't only look at applications of people we already know. But that just makes our job harder, and makes it harder for you to get picked out of the crowd.]
After that, it's not exactly rocket science. I'm looking for a strong record, and the first things I'm looking for are good publications and good letters. Applicants on the first pass are usually sorted into 3 basic categories: invite for an interview, decline, or study further. The publications and letters are the best guide for what pile you'll go into.
Once the pack is cut down, more details will come into play. Some of us will probably read your papers to get a better idea your work. Natural more detailed questions come up: How interesting is your work? How well do you fit our department needs? What teaching experience do you have? Is Harvard a place where we think you would be successful? (For example, what other areas of Harvard might serve as possible points of collaboration?)
The interview helps us answer these questions further. At the end of the day, what we're deciding is if we want you as a member of our department. Research quality is a primary issue, and usually the primary issue. But at this point, hopefully all of the people we're looking at have high-quality research records, with results that we collectively find compelling. So the secondary issues I mentioned -- are you a good fit for us, are we a good fit for you? -- do matter.
In the end, I don't think there's too much you can do to "strategize" your application -- because the main issues are to have a good work record, get people who can write you good letters, and be an interesting person who seems like they'd make a good colleague. I expect that's not surprising anyone. Though I'm sure since I wrote this a bit hurriedly, someone will point out where I've not described things suitably carefully or in enough detail.
Wednesday, January 25, 2012
Collective Coordination of Conferences?
Around this time of year, I get a number of messages from students: I want to take your class, but there's a conflict with this other class I want to take, what can be done... Sometimes a solution can be worked out, sometimes not. It's not an easy issue to deal with. In Computer Science, we take a look at our own schedule of classes, and try to make sure there aren't any particularly bad time conflicts among our own classes, although inevitably there are some hopefully minor ones. Then we try to look at other big classes in related areas -- try not to have our intro classes the same time as the intro economics, physics, statistics courses, etc. Of course we also try to let them know when our big intro courses are, so they don't reschedule classes into those time slots as well. In the end I think we do a reasonably good job.
That was a long-winded roundabout to where I wanted to get to, which is conference scheduling. It's something that I think is becoming increasingly broken -- at least for theory conferences* -- due to the fact that there is (as far as I know) minimal coordination going on with respect to the calendar, and there's an ever-increasing number of conferences and workshops. The near-overlap of ITCS and SODA is one obvious example. The nearly-overlapping SPAA and PODC deadlines are another.** I'm sure one can come up with hosts of others, and that's excluding the issue of trying to coordinate with other adjacent fields. (For many years, INFOCOM and SODA deadlines, as I recall, were within a couple of days of each other -- and July 4th! Not friendly, especially not family friendly.)
I'm not claiming we want full centralization of conference scheduling. But I do think there should be a lot more of it than we have. A lot of aspects of the conference calendar -- dates, how many conferences we have, where they're located -- don't make a lot of sense to me, and I think that's because they don't make a lot sense. I don't know how we arrange for a body to try to look at where we're at and figure out how to make it globally better. But I wish someone would!
* I haven't noticed this so much for other areas -- in networking, SIGCOMM, INFOCOM, NSDI, IMC, and even Allerton have always seemed reasonably spread out to me, but perhaps I just haven't noticed the problem.
** I've thought SPAA and PODC should have some sort of "merge" for almost 20 years now. You're different communities? Fine. Then arrange a permanent co-location agreement. It would be better for both conferences.
That was a long-winded roundabout to where I wanted to get to, which is conference scheduling. It's something that I think is becoming increasingly broken -- at least for theory conferences* -- due to the fact that there is (as far as I know) minimal coordination going on with respect to the calendar, and there's an ever-increasing number of conferences and workshops. The near-overlap of ITCS and SODA is one obvious example. The nearly-overlapping SPAA and PODC deadlines are another.** I'm sure one can come up with hosts of others, and that's excluding the issue of trying to coordinate with other adjacent fields. (For many years, INFOCOM and SODA deadlines, as I recall, were within a couple of days of each other -- and July 4th! Not friendly, especially not family friendly.)
I'm not claiming we want full centralization of conference scheduling. But I do think there should be a lot more of it than we have. A lot of aspects of the conference calendar -- dates, how many conferences we have, where they're located -- don't make a lot of sense to me, and I think that's because they don't make a lot sense. I don't know how we arrange for a body to try to look at where we're at and figure out how to make it globally better. But I wish someone would!
* I haven't noticed this so much for other areas -- in networking, SIGCOMM, INFOCOM, NSDI, IMC, and even Allerton have always seemed reasonably spread out to me, but perhaps I just haven't noticed the problem.
** I've thought SPAA and PODC should have some sort of "merge" for almost 20 years now. You're different communities? Fine. Then arrange a permanent co-location agreement. It would be better for both conferences.
Sunday, July 17, 2011
Manage Intel RAID under GNU/Linux using mdadm tool
You may be interesting to read some history about RAID first.
This article is about managing Intel RAID, with mdadm tool, but some information may apply to others kinds.
To begin, you can find lots of information about RAID under GNU/Linux.
IMPORTANT: for Intel's IMSM support you need at least
version 3.2 of mdadm tool (thanks to Iwan for this information).
Usually, there is a container device (let's call it /dev/md127 in this article), and the RAID device (let's call it /dev/md126 in this article).
Instead of long blabla, this article will give some common commands to help manage Intel RAID with mdadm tool.
To report the RAID information from the Option ROM (for instance "Intel(R) Matrix Storage Manager"):
mdadm --detail-platform
To get general details:
mdadm -D /dev/md127
To examine information (including members):
mdadm -E /dev/md127
To assemble the RAID array inside the container, and/or to start it (the -e option declares the style of RAID metadata (superblock) to be used):
mdadm -I -e imsm /dev/md127
To check the current state:
cat /proc/mdstat
Output sample (with a RAID 10 having 4 members):
Personalities : [raid10]
md126 : active raid10 sda[3] sdb[2] sdc[1] sdd[0]
3907023872 blocks super external:/md127/0 64K chunks 2 near-copies [4/4] [UUUU]
[=>...................] resync = 6.6% (258923904/3907024128) finish=305.7min speed=198882K/sec
md127 : inactive sdb[3](S) sda[2](S) sdc[1](S) sdd[0](S)
9028 blocks super external:imsm
To add it to the configuration file (to be activated automagically at boot):
mdadm --examine --scan >> /etc/mdadm.conf
For advanced commands (including repairing), you should read this.
This article is about managing Intel RAID, with mdadm tool, but some information may apply to others kinds.
To begin, you can find lots of information about RAID under GNU/Linux.
IMPORTANT: for Intel's IMSM support you need at least
version 3.2 of mdadm tool (thanks to Iwan for this information).
Usually, there is a container device (let's call it /dev/md127 in this article), and the RAID device (let's call it /dev/md126 in this article).
Instead of long blabla, this article will give some common commands to help manage Intel RAID with mdadm tool.
To report the RAID information from the Option ROM (for instance "Intel(R) Matrix Storage Manager"):
mdadm --detail-platform
To get general details:
mdadm -D /dev/md127
To examine information (including members):
mdadm -E /dev/md127
To assemble the RAID array inside the container, and/or to start it (the -e option declares the style of RAID metadata (superblock) to be used):
mdadm -I -e imsm /dev/md127
To check the current state:
cat /proc/mdstat
Output sample (with a RAID 10 having 4 members):
Personalities : [raid10]
md126 : active raid10 sda[3] sdb[2] sdc[1] sdd[0]
3907023872 blocks super external:/md127/0 64K chunks 2 near-copies [4/4] [UUUU]
[=>...................] resync = 6.6% (258923904/3907024128) finish=305.7min speed=198882K/sec
md127 : inactive sdb[3](S) sda[2](S) sdc[1](S) sdd[0](S)
9028 blocks super external:imsm
To add it to the configuration file (to be activated automagically at boot):
mdadm --examine --scan >> /etc/mdadm.conf
For advanced commands (including repairing), you should read this.
RAID 10 on Intel ICH10R under GNU/Linux (including HDD devices on Marvell 88SE9128)
After my experience to setup a RAID 0 on Intel ICH10R Vs Marvell 88SE9128; I've recently experienced the setup of
a RAID 10 on Intel ICH10R, using the mdadm tool.
To begin, I've never succeeded to install a bootable Operating System directly on the RAID (tested with Fedora 12, Fedora 13, Fedora 14, Ubuntu 10.04 LTS and Mandriva 2010.1).
So I added an additional HDD device dedicated to the OS, that I plugged on the Marvell 88SE9128 (at the moment, it was more easy with cables).
This time, the OS was bootable, but asap there was more or less I/O stress on drives (OS or RAID ones), the system failed with lots of severe I/O errors, and eventually one of the RAID HDD was declared offline (although it was healthy).
As soon as I plugged all the HDD devices on the Intel ICH10R controller (and after a last OS installation ...), everything became perfect : very efficient and very stable with absolutely no I/O error whatever the stress.
For information, there is no problem with optical devices on the Marvell 88SE9128 controller.
Like in my last article on this subject, I can only conclude that if ever there is a RAID configuration on a system, no HDD devices should be plugged to the Marvell 88SE9128 controller; otherwise the system will be strongly instable and will eventually fail.
a RAID 10 on Intel ICH10R, using the mdadm tool.
To begin, I've never succeeded to install a bootable Operating System directly on the RAID (tested with Fedora 12, Fedora 13, Fedora 14, Ubuntu 10.04 LTS and Mandriva 2010.1).
So I added an additional HDD device dedicated to the OS, that I plugged on the Marvell 88SE9128 (at the moment, it was more easy with cables).
This time, the OS was bootable, but asap there was more or less I/O stress on drives (OS or RAID ones), the system failed with lots of severe I/O errors, and eventually one of the RAID HDD was declared offline (although it was healthy).
As soon as I plugged all the HDD devices on the Intel ICH10R controller (and after a last OS installation ...), everything became perfect : very efficient and very stable with absolutely no I/O error whatever the stress.
For information, there is no problem with optical devices on the Marvell 88SE9128 controller.
Like in my last article on this subject, I can only conclude that if ever there is a RAID configuration on a system, no HDD devices should be plugged to the Marvell 88SE9128 controller; otherwise the system will be strongly instable and will eventually fail.
Some history about Intel RAID under GNU/Linux (dmraid/mdadm)
Although RAID is supported under GNU/Linux since many years, it is not trivial either.
This article is about Intel RAID, but some information may apply to others kinds.
There is at least two tools allowing to manage RAID devices:
- dmraid (Device-mapper RAID tool and library)
- mdadm (controls Linux md devices - software RAID arrays)
Intel RAID can be regarded as pseudo-Hardware-based RAID or Software-based RAID, so the 2 tools can be used.
Anyway, mdadm is more commonly used with modern distribution (for instance Fedora switched from dmraid to mdraid since version 12).
Besides, if you ever have a problem after an OS upgrade, with an existing RAID that you manage with dmraid, you should use the kernel option "noiswmd" which will make the system use dmraid for Intel BIOS RAID instead of mdraid.
This article is about Intel RAID, but some information may apply to others kinds.
There is at least two tools allowing to manage RAID devices:
- dmraid (Device-mapper RAID tool and library)
- mdadm (controls Linux md devices - software RAID arrays)
Intel RAID can be regarded as pseudo-Hardware-based RAID or Software-based RAID, so the 2 tools can be used.
Anyway, mdadm is more commonly used with modern distribution (for instance Fedora switched from dmraid to mdraid since version 12).
Besides, if you ever have a problem after an OS upgrade, with an existing RAID that you manage with dmraid, you should use the kernel option "noiswmd" which will make the system use dmraid for Intel BIOS RAID instead of mdraid.
Thursday, June 9, 2011
Subscribe to:
Posts (Atom)