A lot of the time the WAPs only have 16-32mb of RAM and some kind of hardcoded limit to the number of DHCP leases they can give out (if they don't just exhaust the range instead)
Your local Starbucks probably has half decent Cisco gear, but the independent coffee shop around the corner bought the cheapest WAP in the last Black Friday sale. The firmware hasn't really been touched since 2008 and is running a buggy version of dnsmasq, miniupnpd and an out-of-tree Ralink driver on top of kernel 2.6.
If you think I'm lying, have a look at the firmware of any non-802.11AC DLink or Netgear router. Both companies are getting better but they're at the mercy of the SoC manufacturer (Broadcom, Ralink etc).
802.11AC routers seem to be getting better, mainly due to the bandwidth requirements finally getting beyond 200-400mHz MIPS chipsets. Although [1] might be taking it a little too far.
[1]: http://www.dlink.com.au/home-solutions/taipan-ac3200-ultra-w...
http://www.tummy.com/articles/pycon2010-network/
http://serverfault.com/questions/72767/why-is-internet-acces...
Let me in as soon as anyone of you smart guys has an mvp of a stack exchange (or just stackoverflow.com-) replacement.
I mean, whoever does this might have to hire their own dang-like supermod but I refuse to accept that what we see today is the only option.
Some ideas:
* don't make bureaucratic powers a reward
* when the map and the terrain doesn't match the terrain is usually correct. When the time after time you find that the most useful questions are closed as not constructive then maybe the rules for "not constructive" needs to change.
* from other forums: encourage newcomers to use nicks that don't identify them at least until they get a feel for it
This kind of thing definitely turns me off stack-exchange sites -- especially I find that the sites aside from stack-overflow (which has a larger and perhaps more responsive user-base) are prone to terrible over-moderation and as well as very selective moderation.
There are two bands that are available for use -- 2.4ghz and 5.8ghz. Most newer devices support 5.8ghz -- there is more overall bandwidth available on the 5.8ghz band, but we have had good success deploying only 2.4ghz for public events. Deploying 802.11ac in the 5ghz band with beam steering is something that we may investigate as more clients begin to support this band.
Two of the main issues is contention for air time (bandwidth) and channel usage. Wifi is half duplex, and only one device within a cell can talk at the same time on the same channel. If the access point(AP) is talking, clients(cell phone/laptop/etc...) must listen. If a client is talking, the AP and all other clients must listen. A protocol is implemented for this, CSMA/CA [1]. Think about this for a second -- when someone is transmitting data, nobody else can receive data. This is important (will explain later).
While(in the US) there are 11 available channels in the 2.4ghz band, there are only 3 usable channels. The others overlap and will cause interference if used in the same area. 1/6/11 are the non-overlapping channels. There is a limited amount of bandwidth available in any given area on any given channel. 2.4ghz tops out at about 130mb/s over-the-air (figure about 60% usable bandwidth as a best-case scenario) so about 80mb/s. That's with a single client, clean spectrum, and a single access point. If the signal is weak or if there is interference, this number will be reduced.
Antennas and access points need to be placed and configured (transmit power) in such a manner that you control the number of devices that are within range of them such that their client densities don't get too high (you don't want 1000 people connecting to one access point, wifi's implentation of CSMA/CA breaks down with these densities) but also the targeted clients have a good signal. One thing you must consider that many people don't is, that while you can control the area and transmit power of your access point, you cannot control the client device talking to it. You must take this into consideration also. That client 150ft away on the fringe of this cell is transmitting with full power, likely interfering with another access point 250ft away that can't even hear this AP's signal.
A single low signal client can turn your 80mb/s access point into a 2mb/s access point. An access point talking to a client with a weak signal will 'downshift' and talk at a slower speed -- say 12mb/s instead of 54mb/s -- this makes it easier for the client to receive the data being transmitted without errors. But, this slower speed means more time must be spent transmitting the data, and this is time that the AP can't talk to other clients, and other clients can't talk to the AP. In this manner, a single weak signal device streaming Youtube at 2mb/s can reduce your overall bandwidth on an access point to 10mb/s or even worse. I aim for about 30 devices per access point, with a maximum distance of about 100ft in outdoor environments and 50ft indoors. In practice, this maintains a generally usable speed of about 5mb/s (you'll want to deploy bandwidth management systems to enforce this). Your overall usage will depend heavily on the type of event, but generally we see about 10% of attendants using wifi -- so based on the rule above, about one access point per 300 people.
If the layout of your event is such that this is difficult or impossible (such as a large auditorium/stadium) you can co-locate multiple access points on non-overlapping channels and handle about 1000 clients in a general area. But care must be taken to control the signal propagation if you want to support more clients in other areas as you will be using all 3 available channels thus any other nearby access points(within range) will be cutting into your available bandwidth.
This is complicated by the reluctance of most wifi devices (phones are the worst because you generally can't configure this setting on the client) to let go of a weak signal and grab a stronger one. A wifi device will generally hold on to a signal long after it has become unusable. Many of the bigger manufacturers have ways to mitigate it. With Ubiquiti, you MUST configure the "minrssi" [2] feature and it is buried in a config file on the access point controller. Most consumer grade access points do not support this feature at all.
As I get more into trying to explain this I'm realizing all of the nuances and gotchas that can really make this difficult for someone without experience to engineer and implement. I'm not sure I can effectively convey them in an HN reply but hopefully I've helped steer you in at least the right direction. Sadly, most tech companies that would be contracted to do this type of work are just as ill equipped to design and implement this.
[1]: https://en.wikipedia.org/wiki/Carrier_sense_multiple_access_...
[2]: https://help.ubnt.com/hc/en-us/articles/205146050-OD-UniFi-H...
It would be helpful if APs could distinguish between 'low signal' and 'high error rate', and respond differently. It should actually speed up when the periodic error rate is high, to make the packets smaller targets in the air. Or make them shorter. Or even try to time transmissions to the fit between the occurrences of noise.
Some access points allow you to lock the modulation at a certain rate -- if you know for a fact all of the clients will be able to receive the signal at the required level for that modulation scheme, you can increase your overall effective capacity. Unfortunately this is not usually the case. We almost never get to control the client devices and positions, and without that control, received signal levels can't be effectively predicted.
I think the IEEE struck a balance between simplicity and ease of implementation and features. I don't think the goal was ever to design a standard that could handle thousands of endpoints on commodity hardware.
For what it is, wifi works great. It falls apart when you try to make it do what it wasn't designed to do. There have been missteps along the way, but overall I think the good outweighs the bad.
Lets not throw the baby out with the bathwater.
Many of them have not been without their failures. GSM had several long-standing security issues, some of which went on uncorrected after disclosure [1]. WEP was designed in the 90s and I believe there are a large number of security/encryption methods designed in the 90s that have since been proven flawed, either in design or implementation (RC4/MD5/SHA1 to name a few) Bluetooth has gone a completely different direction than it's original design and is also not without its failures. But the main difference is, each of the standards you listed was designed for a specific task, and works well in doing what it was designed to do. When you leave that area of designed function, they start to break down.
In relation to the wireless technologies(GSM/HSPA/CDMA/LTE, et al...), their design goal was indeed massive systems with 1000's of clients. They employ various technologies that would generally be cost-prohibitive or otherwise impractical (such as GPS synchronization) in the commodity consumer market. I haven't seen the price tag for an LTE tower site, but I bet it is several orders of magnitude larger than a $120 consumer router. Wifi was never designed to do this.
I agree that wifi is not unique in its success, nor is it unique in its failures. This extends to most entities in general. All have their failures and successes, including IEEE.
On a side note, I have never been that concerned with wifi encryption. The vast majority of wifi access is access to the internet. If you are not securing your data before it leaves your control, the short hop over to the access point is the least of your problems.
We haven't deployed them mostly due to cost, but also because we have had great results with Ubiquiti.
:)
PS: Reporting live from hall 2. good talk so far ;)
Edit: Their online infrastructure is probably seperate though.