Adam Fields (work stuff)

Some tips on getting started with Vagrant and Chef

We have recently switched from a manually configured development environment to a nearly fully automated one using Vagrant, Chef, and a few other tools. With this transition, we’ve moved to an environment where data on the dev boxes is considered disposable and only what’s checked into the SCM is “real”. This is where we’ve always wanted to be, but without the ability to easily rebuild the dev environment from scratch, it’s hard to internalize this behavior pattern. Cruft builds up in the dev boxes, and it starts to slowly drift out of sync unless a lot of manual intervention is applied. Rebuilding the VM is not something you’ll want to do (or have to do) very frequently, but it’s a good feeling to know that you can with very little pain, if it’s needed. This still doesn’t completely eliminate development cruft, but the hope is that it can significantly cut down on it. If you’re worried about running vagrant destroy, that’s a hint that you might have done something wrong.

This post covers our ruby dev environment on Mac hosts. For other platforms it will be slightly different, but the principles are the same - use vagrant to manage your underlying machine configuration, automate as much of the rest as you can, and keep all important data resident off your dev boxes, checked into scm or using another redundant remote mechanism. As someone who’s been doing unix system administration as a sideline to development for about 20 years, I’m really impressed at the extent to which the automation tools have improved in the past few years. I did not have any direct experience with configuring chef when I started this, though I’ve been familiar with the concepts and have used other automated configuration and deployment mechanisms.

The configuration took a few days of solid effort to get up and working to the point where it was usable, and then a few more days to work out the kinks and figure out our preferences. While working through it, it was pretty easy to identify what the next step was given what wasn’t working. Work your way clockwise around the diagram - get vagrant up and running, then do base installs, then work on getting your source tree in place, then get it working, then import dev data.  Instead of distributing ssh keys to the individual VMs, we use agent forwarding to allow each VM to use the keys from its host. The final config consists of only a handful of files. Depending on the complexity of your environment, you may need some additional scripts:

• The Vagrantfile which determines the vagrant and chef configuration.
• A Cheffile which specifies to librarian-chef which cookbooks to get.
• A custom shell script which populates ssh config files, sets up user and database permissions, and performs project checkouts with the appropriate rvm environment.
• A shell script to run on the host to add the host’s ssh keys to ssh-agent (probably automated by launchd).
• A custom /etc/hosts file to insert into the VM config.

These files are checked into SCM, so bringing up a new dev box is only a few steps (all but the last step only ever need to be done once per machine):

• Install virtualbox: https://www.virtualbox.org/wiki/Downloads
• Install vagrant: http://downloads.vagrantup.com
• Make sure your key is on the server for the dev config checkout.
• Check out the dev config repository.
• Run the ssh-add script to bring your keys into the ssh-agent.
• Install librarian-chef using any local ruby (gem install librarian-chef)
• Install the librarian chef vagrant plugin, so vagrant will automatically fetch your cookbooks (vagrant plugin install vagrant-librarian-chef)
• Set up any local path location and config variable overrides in  ~/.vagrant.d/Vagrantfile (optional)
• Bring up your dev environment with vagrant up.

We use vagrant synced folders to mount selected folders in the host’s Dropbox folder and the separate project tree where checkouts are placed, to share these files between the VM and the host, both for letting developers use their own Mac-native environment to edit files in the source tree and for importing data via dropbox (Rather than checking them into scm, our database test packs are distributed via dropbox, and the provisioning script looks for them there to do the initial import.). Chef handles getting the proper ruby versions installed, and then bundler ensures that the gems needed for each project are present. We have used bundle package and checked in our vendor/cache folder, which greatly reduces the amount of time it takes to install gems.

With this configuration, the VM has its own copies of the databases and its own source trees. The databases and local configuration files (with some critical exceptions that are always overwritten at provisioning time) are wiped out in the case of a vagrant destroy, but otherwise preserved. The source trees are always synced with the host, so they will survive the destruction of the VM, but they can of course be manually wiped if needed.

Some random notes:

• There was some complexity in having the provisioning shell scripts running as the vagrant user (instead of the default, which is root), with access to the ssh keys via the ssh-agent forwarding. The best solution I found was to make a separate script file, then call it with sudo -u from the provisioner. All of the configuration that needs to be done as the vagrant user (rvm setup, bundler installs, scm checkouts, environment config etc…) goes into that script.
• The default VM runs with very little RAM and only one CPU, which makes compiling (especially new rubies under rvm) extremely slow. You’ll want to bump this up.
• There’s a balancing act between what should be configured by chef and what’s easier to just do with shell commands. Most of the simple configuration settings and individual packages are easier to do with the command line.
• There seems to be an intermittent issue where a suspended VM will be unable to pick up a DHCP ip address upon resuming, which causes it to hang indefinitely. An interim solution (found in this post) to this seems to be to execute VBoxManage guestcontrol <vagrant machine id> exec “/usr/bin/sudo” —username vagrant —password vagrant —verbose —wait-stdout dhclient from the host.
• I find it odd that there’s no way to specify local Vagrantfile changes that take precedence over the project files. This means you either have to design your Vagrant config in such a way that you’re setting variables which can be overridden locally, or people have to edit the project Vagrantfile directly (and risk accidentally checking in their customizations). This seems likely to cause problems as different developers are going to want to use machines with different amounts of memory. We’ve temporarily worked around this by using global config variables and only setting them if they’re not already set.
• Vagrant uses its own config file for controlling chef commands in a way that differs from chef’s own syntax, meaning that chef configs can’t be reused outside vagrant. I haven’t yet found if there’s a way to import generic reusable chef configs directly.

Our Vagrantfile (with some custom config removed) looks like this:

Setting this process up has definitely been some work, but I think it’s worth it once everybody gets set up. There are a lot of moving parts, and a lot of individual edge case problems to solve. But the nice thing about this is that once you do solve each one, those changes can be globally applied to everyone with little extra efforts. We’ve worked our way through a number of issues in a very short time - I’d love feedback on this from experienced vagrant users.

Why I’m not buying Bitcoins

I’m not an economist, but Bitcoin seems pretty scary to me right now. It seems attractive as a decentralized currency, but there are a few properties that are worrisome.

The value (exchange rate) has increased in the past few months past the point of “convenience money” for most. At an exchange rate of somewhere between $10 and $30, there are a large number of people who will buy some without fear that they’ll lose their money, and more importantly, at that level, you have a large number of buyers who bought in early enough to sell at slightly higher rates and still make a comfortable profit. Buying at $30 and selling at $170 (where we are now) is not a bad run by any measure. People are buying in now, but there’s a limited number of bitcoins in circulation and mining can’t keep up with the demand, so people must be selling. Who’s selling? - it’s the people who bought in earlier and are now taking profit on their earlier purchases. Flash forward a bit and imagine that the exchange rate has reached $500. If you want to buy then, you’ll be doing so from someone who bought in earlier and is looking to make a profit. That would be the people who are selling now plus the people who are buying in now. Now flip it around and say you want to sell at $500. Who’s buying? At that point, maybe the media frenzy has died down, or maybe there’s a fresh influx of people who think it’s going to go to $5000. Maybe it will. With no central clearinghouse, there’s no guarantee of being able to sell at any given price, and it doesn’t seem to me like this scenario is set up for long term success. At somewhere in this range and above, you’re talking real money for a lot of people, and the casual speculators will disappear.

Now, let’s look at the transaction rate. MtGox is the largest exchange, by an order of magnitude. As of the time of this writing, over the past 30 days, they have done 2172994 transactions, which is about .83 transactions per second. For a global currency whose market cap is measured at over a billion dollars, this is an astonishingly low number of transactions. (Let’s put that in perspective a bit - so far just today, Google stock was traded 1,990,139 times. Google’s stock price is determined by roughly 30 times as many transactions as all of Bitcoin’s.) Demand is high for now, but liquidity is low, and when it comes time for a lot of people to want to extract some value, there simply aren’t going to be a lot of interested buyers. Most of the previous buyers will have gotten in at near or above the current trading price and so will be waiting for it to continue to rise, a high enough entry price will chase away new buyers who can’t afford to lose their investment, and any dips will keep away the marginally interested people who were only showing up because of the media attention.

I expect the exchange rate to continue to rise for a while, but there’s really no way to know how high it will go, and I think eventually the trap will close on everyone all at once. 

I’d love to hear arguments why I’m wrong about this, but I think the time to buy in has already passed.

How I do project planning (and why OmniPlan doesn’t help)

I do a lot of medium-term software development project planning (typically 6-18 months). Here are the steps I use for doing project scope estimating (which is a distinctly different thing from tracking progress against the initial plan). After figuring out what rough timeframe the project should be targeted for, we:

1. Figure out what the tasks are and break them up into logical groupings.
2. Chain dependencies for tasks that cannot be done simultaneously.
3. Estimate how long they’ll take if one developer does them, setting the amount of effort. This is usually done on the scale of days per task, and any task that takes less than a day should be grouped into a larger bunch that can be estimated on the scale of days. We’re not micromanaging here, just trying to get a sense of the effort involved.
4. Fix the effort for all tasks, then add developers (with assigned salaries or hourly rates) to each bundle of tasks to bring the total time in under the deadline.
5. Be very aware that this is just an estimate, that adding developers to tasks doesn’t tend to strictly reduce the time by the number of developers assigned, and that a certain amount of padding is also needed for communication and integration. And do it anyway, because a wrong plan to measure against is better than no plan.
6. Resolve allocation conflicts.
7. Rationalize by hand any inconsistencies that don’t make sense (see step 6), and re-examine the long-term project timeframes (figure out if some tasks should be bumped to subsequent phases).
8. Answer the single most important question in project estimation - “given a time range, how much is this project or sub-task grouping going to cost me?”. This answer is critical - it determines the proposed budget for the project, and helps determine if a part of the project is worth doing.

Changing ulimit successfully for databases on linux

Databases are a pain, but one thing seems to bite more often than anything else, especially at scale: per-user limits. OS creators have thus far not seemed to have caught on and made these settings either easy to set or easy to make persistent. Typically, when you run a production database, that’s going to be the only thing running on the machine, so it’s okay if it uses all available resources, and the default multi-user settings designed to protect users from each other make no sense. (Protecting yourself from runaway processes is another story, but generally speaking, you want to make your entire machine’s resources available to your database, otherwise what’s the point?)

This post is aimed at CentOS/Amazon Linux. If you use another distro, your steps will vary, but may be similar.

Here’s what I had to do to make this work (I’ll use the mongodb example):

1) Add lines at the end of /etc/security/limits.conf to increase the system limit for open files and number of processes, getting badly bitten by the apparently undocumented feature that newer kernels require you to specify nproc limits user-by-user and wildcards no longer work. You may also need to add the root user here - it’s unclear.

2) Modify /etc/init.d/mongod to set the runtime limits before the server is started (I’ve included the whole init.d script here for reference, in case you don’t have one):

3) Start up the server, and verify that this worked with this extremely helpful script.

Ridiculously useful bash snippet to return actual ulimit values for a given process

From the MongoDB docs comes this very useful bash function. In a shell, do: Then you can get the ulimit values of a running process with e.g.:

return-limits mongod 

Evernote, you really messed this one up, and you’re making it worse.

So… Evernote was hacked. Yay. Except that their “recovery” procedure is seriously, significantly, embarrassingly flawed. I’m flabbergasted.

The procedure is as follows:

1. Log in with your old password.
2. Change your password to a new one.

Yes, that’s right. All you need to change your password is your old, compromised password, and there’s no other verification required. No email verification, no secret questions, no nothing.

Evernote, I don’t think you understand how serious this is. This needs to change, immediately.

(If you have an evernote account, I advise you to go change your password NOW. Before someone else does.)

Security implications of oauth and leveraged access

So - twitter was hacked this week. Which happens to the best of us, and is going to happen more often in the future. They invalidated the passwords for 250k user accounts (though anecdotal reports would seem to indicate that it’s more than that). But here’s the strange thing - even though my password was invalidated and inactive, the oauth tokens for apps I’d approved access for still worked. And continued to work even after I’d changed my password. If they thought it was possible that my account was compromised, why weren’t these tokens deactivated, even temporarily?

Granted, most of these access tokens are for mobile apps, or for using my twitter credentials to post on someone else’s site instead of drawing from my twitter feed, or for enabling other apps to post _to_ my twitter stream on my behalf, but some of them are reading my stream, including direct messages, and someone with my password could have potentially spread the damage around to other services (adding significant hassle to the cleanup), and also added more without my knowledge. (It’s possible that they deactivated more recent ones.) They did ask me to review them after resetting my password, but it was entirely optional, and a less savvy user may not have known what to look for.

This seems like a serious and surprising oversight. I think most technical people barely understand the implications of authorization delegation, let alone everyone else. It seems like it should have been a reasonable precaution to at least turn all of those off until my password was changed.

The difference between task and list managers

There seems to be a lot of confusion about the difference between task managers, to-do lists, and checklists, and why you’d want different apps for them. They’re three very different working patterns with different goals, and they require different UIs to be successful.

Disclaimer: I don’t make any presumptions of being an expert user of these apps. I am not a “productivity guru”. I am probably missing some very useful features of some of these apps because they haven’t surfaced them well enough to be obvious, and I resist modifying my natural workflow to do things the way apps want me to without a good reason. I have work to do. I’m productive because I do my work instead of fiddling about with settings, and I primarily use these tools to help me not forget important details, not to tell me what I should be working on. Everyone needs to find their own style, and may find different UIs more or less intuitive. This is some discussion about what I use now and how well it works for me.

A note on Sync: task managers of all flavors are useless if you don’t have them with you when you need them. I consider sync to be critical for everything except the most basic and narrow use cases. All of the apps listed here have iOS and Mac versions that sync, except where noted.

There are many different classes of tasks. Some examples from my daily life:

1. things you have to do right away
2. things you have to do later at a specified time
3. things you have to do later but you don’t know when
4. things you have to do later but it doesn’t really matter when
5. things you have to do after some other thing is done
6. things you have to do frequently but on an irregular schedule
7. things you have to do every day
8. ad-hoc groups of things you have to do together
9. regular groups of things you have to do together often

Task managers, as a class of applications, aim to keep your entire perspective across many different contexts. They can handle complicated metadata like start and due dates (and reminders), dependencies, hierarchies, priorities, task status, task states, estimated times, and notes. 

My primary store of tasks for the first five of these is OmniFocus. (I’m told Things is very similar. Having bought OmniFocus, I don’t see a good reason to spend a lot of money on Things. If someone wants to make the case that Things is significantly better than OF in some way, I’m all ears.) I don’t do GTD, and while OF is fairly optimized for the GTD use cases (if you want to do GTD, it’ll work well for that), it is a flexible task management system with a lot of applicable metadata. It’s always seemed too much work to me to set up and manage contexts, and I don’t strictly use OF to tell me what to work on next. I use it primarily as a store of all of the tasks I have to do at some point, things I don’t want to forget, and projects I’ll probably never get to. I use the project hierarchy extensively, as well as due dates for the current project. It is not representative of the actual list of tasks I’m working on next, except for the OF project called “Do these next”. (At one point, “Do these next” was a context, but I found it easier to just make it a separate project.) My job is such that pretty much as soon as I’ve put something on the list to do next, there are going to be five or six other things that pop up that need to be done first. I use OF largely to keep myself from getting too far off track over time. I try to be judicious about actually killing tasks that are on my list that I never really intend to do, and moving them to inactive projects. I frequently come up against tasks that would be nice to do, but never end up being important enough to take priority over more immediate concerns. I’d say most of those tasks end up having about a 20% chance of ever seeing the light of day before they’re obsoleted or pushed off indefinitely. For collaboration, we maintain a separate ticket system with to-do items (class #10: things other people have to do), but those tickets are usually higher-level while the tasks that go into OF are much more detailed and very specific to me and how I work.

The single most important aspect of any task management system is priority management. I need to figure out what I’m doing next, and ignore everything else until I’m done with that and have to figure out what to do next next. If your tasks are clear-cut enough that they will naturally form a priority queue, OF can probably help you manage that and tell you what to work on next. I often have to re-evaluate anyway, so that’s not as helpful for me. I use OF to keep all of my work-related tasks. OF especially has a LOT more power to slice and dice your task list than I even come close to using, but I feel like I have a pretty good handle on my task list even with just the features I’m using.

While it lacks a good organization scheme for larger-scale projects, I’m finding that Apple’s Reminders.app is very handy for keeping non-project-related personal tasks. It feels like a to-do list, but it also has reminder times (limited but helpful) and location-based alerts (which sort of work, but generally aren’t granular or flexible enough to be useful for me). It has the critical ability that I can easily share lists with my wife, and if you have an iOS device or Mac, it’s already included. For many people, that may be all you need, but I find the lack of hierarchies limiting in my organization. I use it for things like remembering to return items to stores, make appointments, and print photos. I use Reminders for some personal items in classes #2-#4, as many items as I can shoehorn in from class #6, and a lot of class #7.

A to-do list is a simple ordered list of items.

Clear is by far my favorite example of this. It lets you keep multiple lists, reorder them easily, and it has a very pleasing UI and sound effects. I use it primarily for keeping items in class #8. This will often encompass things I have to collect before leaving the house, or things to buy for a party. The flexible UI makes it very easy to adjust the list as I go, priorities can be adjusted by moving items up or down, and having it in a separate app allows me to concentrate on just that next list of items without worrying about anything else. Listbook is also a nice app for this, but the UI for Clear just blows it away. In the latest version, Evernote has some basic to-do list capability (which they call checklists), but I don’t find it useful for that much.

I consider a checklist to be a special kind of to-do list, where there’s a template for items, and every time you start a new iteration, you have to do everything (or most things) on the checklist.

Class #9 is the checklist. I haven’t yet found a checklist app I like. I would use this for managing the scope of repetitive actions, like test plans or deployment checklists. In the past, I’ve used OmniOutliner for this, but it’s not great (and has no iPhone version). I like OO for making outlines, but a checklist isn’t quite the same thing. I’m trying out TaskPaper (I picked it up recently on sale) and Workflowy (someone sent me a referral code) for this, but I haven’t had a chance to give either of them a whirl yet, though they seem like they won’t offer too much advantage over OO. They all still have the standard “make a list, save it as a document, then copy that document” workflow, which is substandard. I’d really like to find some checklist manager which can easily manage a bunch of different lists and “deploy” them as needed with the options to run a whole list at a time.

Certainly anything kept on a to-do list could fairly easily be kept in a plaintext file or a note app as well, but it’s nice to have a dedicated app with an intuitive UI that lets you easily reorder items, insert in the middle, and check items off individually as you go. These are the differences between a tool that can do what you need and a tool that does what you need.

I’m sure I have much more to say on the topic, but I hope that helps a little.

Kickstarter status check

To date, I’ve backed 15 kickstarter projects, all of which have been funded. Of those 8 have delivered. I’m not going to go into detail on all of them for various reasons (some are gifts that I don’t want to spoil), but here are details on some of them.

On time or as close to it that I didn’t really notice:

• The Cosmonaut, a wide grip stylus for touch screens: Drawing on an iPad is necessarily low-res because of the large touch targets meant for fingers. There are some workarounds. This stylus embraces the large form factor and turns it into more of a whiteboard marker style. I like it. I don’t use a stylus very often, but this one works well for when I do. I don’t know if I’d buy it again, but I like it.
• Coffee Joulies: They’re little blobs of stainless steel with some kind of wax in the middle  that you put into your coffee, and they bring the temperature down to the drinkable range quickly and then retain heat to keep it warm longer. Marco Arment was famously unimpressed. I have found that they work really well for me. Using my regular Contigo cup, my coffee was previously way too hot to drink for about 20 minutes unless I added an ice cube, which had the side effect of making it get cool much faster. With the coffee joulies, it is drinkable in about a minute, and stays warm noticeably longer. I don’t know if I’d buy them at retail price - the backer discount was substantial. They are admittedly expensive, but that doesn’t take away from the fact that they work for me and I use them every day.
• TiGr Titanium Bike Lock: I love this thing, though it has a few hiccups. There’s no place to keep the lock cylinder when it’s not used. This model is not quite long enough to lock up both wheels and a post, because my hybrid bike has a long wheel base and slightly wider wheels than many bikes (John has graciously agreed to let me exchange it for a longer one when available). It is however, really flexible, and has enabled me to lock my bike up much more easily in some places where it wasn’t previously possible. They can be easily chained to get around large objects. It is also very light. Expensive, but not compared to my bike. I would definitely buy it again.
• Dark Sky for iOS: A high-precision weather prediction app that will tell you with good accuracy whether it’s going to rain in the next hour, and about for how long. I use this ALL THE TIME. Buy it.
• Find my car smarter: A bluetooth 4.0 low-power dongle with an app that pings in the background to automatically keep track of where you left your car. Useful, and it seems to work, but we don’t drive much. I don’t regret backing this, but I probably wouldn’t buy it again.
• Smarter Stand for iPad: I absolutely love this thing. It’s a set of clips for the iPad Smart Cover that open up new configurations for how it can stand up. Great idea, great implementation. Buy it.

And some delivered but not so on time:

• Elevation Dock for iPhone: I like the Elevation Dock, though it’s been plagued with problems. It was released (late) just before the iPhone 5 changed the connector, which annoyed a lot of people, and the solution thus far has been a hack. I still have my iPhone 4S, so that’s not an issue for me yet. But I’ve found the circuit board to be flaky, and have had to have both of them replaced. Their support email has a turnaround time of days, which is unacceptable. I still like this, and I use it, but I would not buy it again.

And some that I’ve not yet received:

• Pebble: E-Paper Watch for iPhone and Android: I’m not really sure why I backed this. It seems like a great idea, and I have no idea if they’ll pull it off. I hope it’s great, but it may not be. It’s late, but the founders clearly opened up a vein of latent interest they weren’t prepared to deal with, and they’ve been sending reasonably frequent updates of progress. They asked for $100,000 and raised over $10,000,000. I can forgive this for being a totally different project than they thought they were getting into.
• The Nifty MiniDrive: Also late, but it seems like they’re actually very close to shipping. (Update: Received a shipping notification the day after I wrote this!)
• Double Fine Adventure: It’s a Tim Shafer adventure game. No-brainer.
• Shadowrun Returns: Shadowrun was one of the best RPG systems I ever played, and I love the universe. Clearly I was not alone. Ambitious, but they raised a lot more than they asked for, and have been delivering steady updates.

So far, no real doozies, and few things that I use and enjoy often. I’m pretty happy.

Wifi performance and the new iPad (counterintuitive Airport settings for advanced users)

The iPad 4 (and iPad mini, though I didn’t test with one) claims to have up to twice the wifi performance as previous models. While trying to configure my Airport Extreme to get the best performance, I discovered some interesting and counterintuitive results about the settings. (This probably also applies to the newer Airport Express, though I don’t have one.)

tl;dr: The Wireless Options screen is a performance deathtrap. Leave everything here at the defaults for best results. Most changes on this screen will degrade performance.

(UPDATE: Added iperf results to the bottom.)

The longer answer: it seems that you get the absolute best wifi performance (for iOS devices, this is 150Mb/s, but laptops can go faster) if you let the router determine the protocol (radio mode) and channels to use automatically, and set the 5GHz network name to be the same as the 2.4GHz network name. I’m measuring performance by the speed at which the Airport is telling me my devices are connecting (which seems to correspond to real-world throughput).

Update: These tests are relatively informal, but I’ve been able to repeat them several times. I’m definitely curious if others are seeing the same results. I have tried running the Ookla speedtest app to verify, but at the moment, I don’t really trust its results. In theory, at a 150Mbps data rate connection, I should get 50Mbps down (the speed of my cable modem), and I’ve never seen it top 20 on the iPad. I do get 50Mbps on my wired desktop. I’ve seen speedtest results vary widely by which server you’re attached to, and I can’t figure out if there’s a way to change that on the iOS app, so that may be the difference. It does seem to vary with the connection data rate speed, but not enough that I’m comfortable with it.

First, the network name. If you specify a different name for the 5GHz network, they will appear as two separate networks in the settings of the iPad, forcing you to choose one or the other to connect to. In this case, even choosing the 5GHz network explicitly gave much worse performance. I gather that the protocol enhancements they’ve done require channel bonding across both the 2.4GHz and the 5GHz range, and if you choose one or the other, you give up that option. Even signing in to both networks did not reliably improve performance. Switching back and forth did momentarily increase throughput, but not to the highest levels.

Here’s what happens to the iPad wifi data rate if you have a separate network name for 5GHz.

Connected to the 2.4GHz network, it’s not terrible, but we should be able to do better:

If you connect to the 5GHz network, it’s surprisingly even worse (it started out at 150, and rapidly deteriorated):

Second, the radio mode. 

The default radio mode options screen looks like this:

But you can get additional options by holding down the (wait for it) Option key while clicking the radio mode:

I had previously had the radio mode set to all 802.11n, because I have a separate network for the few remaining 802.11g devices I have, and I thought I was benefitting myself by preventing the network from dropping down to g speeds to accommodate those devices. This turned out to be a counterintuitive mistake - if you lock the radio mode to 802.11n, it CANNOT achieve maximum throughput, and it cripples most modern connections. The only acceptable radio mode I’ve found is 802.11a/n - 802.11b/g/n (Automatic). After making these changes, nothing is preventing slower devices from connecting to your network. If you want the maximum throughput, you’ll need to manually ensure that everything can use the faster connections.

With the router set to n-only, here it is connected to the 2.4GHz network:

And the 5GHz network again tanks very quickly (and having no separate 5GHz network name here seems to make little difference):

I’ve only tried it a few times, but it seems like in any configuration other than fully automatic, connecting explicitly to the 5GHz network may appear to give fast performance, but it will quickly step down to something slower. The only way I’ve been able to get a sustained 150Mb/s connection is to leave the Airport Extreme in fully automatic mode.

Here’s what it should look like:

As a bonus, here’s a 2010 Macbook Pro hooked up to the same network in fully automatic mode:

Update: and a Retina Macbook Pro:

Turning the router back to n-only mode also craters the rMBP data rate:

At the suggestion in the comments, I’ve tested this with iperf, and it has completely substantiated my results. Using fully automatic, I get a reported actual 70Mbps transfer rate from iperf, and that’s the only setting that remains high over time.

Here I started out on automatic (60-70Mbps), then dropped down to N-only (barely 1Mbps), then split the networks and connected to the 2.4GHz network (25 Mbps):

Choosing the 5GHZ network gave good performance initially, but then it tanked to below 1Mbps, and didn’t go back up.

Repeated testing with the fully automatic network over time showed a sustained high rate:

Resist the urge to tinker with these settings.