Sunday, May 15, 2011

How to make WIFI work at tech conferences (Part 1 of N)

Good WIFI at tech conferences is hard. Very hard. Usually it doesn't work.

At JSConf 2011 Meno Abels and I tried to make it work. All the credit really goes to networking guru and all-things-software Meno. Also thanks to for awesome work on the connectivity and the access points. In the following paragraphs I will walk through the challenges one faces when it comes to WIFI at conferences. This article will stay quite shallow technically. If I ever have more time I will dig deeper.

0. Basics
Dear conference organizer, this is the part that can be easily fixed: You need to have a person that takes care of the WIFI as a core priority. The WIFI will break and you will need someone who is willing and capable to put on the wetsuit and jump into the shit. E.g. at least one of your access points will be overwhelmed at any given time. Many things can be done to fix this. Somebody will have to do it.

1. Never trust anyone
Now you booked a venue and they say that they can handle the WIFI for you. Chances are, they are lying. In any case, if you want to go this route, ask for references and call the references. Purespace wanted to handle the Nodeconf traffic over a 2Mbit/s down, 300 kbit/s up DSL connection. That will not work. Chances are you have more than 300kbit/s in TCP ACK packages for your downstream traffic. At nodeconf Stephouse saved the day by coming in on 5 minute notice and installing a microwave link in about 45 minutes (Remember the wetsuit thing from above).

2. Number of attendees and number of devices
Calculate 2.3 devices per attendee.
The primary problem this creates is overwhelmed access points. What can you do to fix it:
  • Monitor the number of people attached to each access point.
  • Add another access point in zones where more people come together than you expected.
  • Use as many access points as possible. Lower the antenna power as much as possible to decrease the range of each AP.
  • Never have two APs close to each other on adjacent channels.
  • Don't use encryption. This will be painful, but it really relaxes the CPU of your APs.
  • People sometimes move in groups and stay attached to an AP while others move in and go onto the AP because it is the closest one. This creates an uneven distribution of people over the APs.
    Easy fix: Throw everyone off the AP. The devices will then try to connect to the closest AP again.

3. Unknown Building, Temporary Setup
Conferences are by definition temporary setups. You will have no time to tune your system under real world conditions. But still, you will need to update the configuration throughout the conference to make things work better under real load.

4. Bandwidth
Calculate 100KBit/s per attendee in both directions.
You can live with a little less up-link traffic but don't go with consumer level DSL. In case you cannot get that kind of bandwidth from a single provider, take all you can get from multiple vendors and use the software that Meno built for to aggregate the links (Warning: Only an option if you have a black belt in networking kung fu.)

5. Bandwidth in the Air
Effective bandwidth per WIFI channel is 20 MBit/s. WIFI has 11 channels. That means that you will never get more that 220 MBit/s in the air, ever. This bandwidth has to be shared by everybody in the room. If you put 5000 people in a relatively small room, then your WIFI will be slow. There is no way around that. It is simply physics. (You may be able to add the 5GHz channels, but we recently experienced problems with some Apple devices.)

6. People
People are the primary problem for conference WIFI. Actually not people but the software running on their computers which they did not disable. This involves bittorrent clients and backup software. One person at JSConf uploaded 9.6 GB in the first 30 minutes of the conference. This means that one person used almost 80% of all bandwidth. Identifying these "powerusers" will get your conference a long way to good WIFI. Usually you will only have an IP address, so your only option is to either block the person entirely or to block the remote IP where the traffic is going. At JSConf we introduced social traffic which links all traffic to Twitter identities. This way we can used Twitter @-messages to ask people to disable rogue services.

7. JSConf learnings
All of the above we learned at previous confs. This is what we learned at JSConf:
With a few 100 people at a conferences there will be a couple stupid persons in the audience. Redirecting all traffic from to goes a long way in fixing this problem.
Using an auth service such a social traffic requires white listing of IP addresses. Make sure you highjack all DNS traffic (all on port 53 regardless of DNS server used) so that you are able to control e.g. the IP address you white listed for

Now go back and read point 0. The most important thing is to have somebody who cares and gets their hands dirty when it is most needed.

Wednesday, May 11, 2011

Unsolvable Problems – Why micro libs suck.

OK, actually I like micro libs. The title of this post is only part of my Hacker News Optimization (HNO) strategy, developed by my PR agency.
There has been some heated discussion in my Twitter feed over the last days and following #jsconf about the benefit and usability of micro libs.
Now one can make many good points pro and contra using micro libs but one stood out to me the most
Micro libs suck because they have weak cross browser compatibility.
As should be obvious, this is a classic bullshit argument. I can prove it wrong easily: The ultimate micro lib Vapor.js has the best cross browser compatibility of all JavaScript code that has ever been written.
Coming back to the original argument, even joking aside, it is still wrong. There might be individual micro libs with certain bugs but that is true for all environments. Roughly 99% of all jQuery modules are badly written and contain massive bugs. The situation might be better in big toolkits such as quooxdoo, dojo and Ext but why is that really?
Right, these guys actually test their stuff.
Cross browser or interoperability problems between micro libs are actually a problem of insufficient testing. Now the good thing is that we, as the JavaScript community have one pretty unique feature that will help us solve the testing dilemma:
The founding myth of the JavaScript community is not based on Perl-Angst.
Thus we may copy everything that made CPAN successful without falling prey to not-invented-here-syndrom that made gems, pips and all the others only sub-par competitors.
Izaac showed great vision at #nodeconf when he described the future of npm using TAP in the testing layer. TAP, which comes from the Perl community but really hasn't anything to do with it, is a protocol for test-runner output. It is really easy to produce, human readable and fairly easy to consume as a machine. With TAP everyone can use their favorite testing framework, even cucumberish natural language comprehension using regexes, if only it supports TAP output. On the other side we are able to build awesome tools that process the TAP output of your tests to do awesome things with it.
See for example this page that shows automated test results gathered from people installing Archive::Zip. So it mostly passes everywhere but there are some weird outliers that go wrong. Does that sound familiar? Yes, this is just like things happening in browsers.
Imagine if the awesome by Mr. Thomas Fuchs had an extra select box like this:

Using our unified testing infrastructure each library would be tested in all possible browser environments. The select-box now allows you to select which environment is important for you and only modules compatible with that environment will be shown to you. Remember, it is perfectly valid that zepto.js chooses not to run in IE. If that is important to you, update your selection and it will no longer be recommended.

Closing words
Lets build this infrastructure. I for one donate my free time starting now.

PS: Everytime I say "micro lib" you may read "module" instead :)