There's a simpler solution - stop buying access points with inbuilt (ie, crappy) gain antennas.

Some have _PCB printed_ antennas that are just plain crap at everything.

Spend a little more money, buy something 2x2 or 3x3 with external antennas worth a damn, and you'll find your reach and throughput drastically increasing.

The number of houses I've been in lately with crappy wifi due to their APs having onboard antennas is just plain ridiculous.

The inter-frame spacing is mostly the same. It's tiny compared to contention window handling and actual frame duration. It's not really the main reason for drastic slowdowns in mixed networks.

The main issue in mixed networks is:

* having to enable RTS and CTS-to-self frame protection to interoperate with legacy stations that don't understand MCS rates, and
* just sheer length of non-aggregate frames (ie, 11abg frames, and 11n stations that aren't doing aggregation - eg if they're doing voice data that isn't being aggregated into A-MPDU or A-MSDU for whatever broken reason they have.)

The other major thing is that most consumer grade APs don't do fair scheduling very well, so when you have multiple stations all doing traffic, they can end up with an uneven balance of traffic, causing drastic reductions in throughput. I won't go into the handwave details unless people care; I've written about it before.

Now, _I_ get ~ 170mbit TCP throughput on FreeBSD -> FreeBSD atheros 11n devices (AR9280 2x2, 5GHz) _WITH_ RTS/CTS and legacy interoperability enabled. Things just tend to slow down when multiple stations show up.

.. FreeBSD person here.

Which ports in question? I was under the impression that PHP/apache ports are kept up to date in the ports tree.

Erm. Let me rephrase that.

We in the tech industry realise that a significant amount of what is new is actually old, just faster and shinier. A lot of the concepts that people are exploring now were explored in the 1970's, then forgotten during the microcomputer revolution when the computing world fell inward, away from expensive networked multiprocessor machines with lots of shiny IO and inward into stand-alone, single-CPU devices with very cheap IO. It's now mass produced, really fast, very well connected.. but a lot of the concepts aren't new.

Software and hardware is still failing, even today. Sheesh, at the risk of sounding inflammatory - anyone in the tech world would NOT make the argument that software and hardware is getting more reliable.

A photograph of the device gives more than just background about the device. It gives you a context, it gives you a setting. It gives you a hint about the state of the world at the time the device was introduced.

You're obviously not an archeologist.

Question: ask teachers if they really do get that holiday time.

The bad or burnt out ones: they take the holiday time.

The good ones: are learning more stuff during that time, going to meetings, etc.

The really good ones: are spending that time going over the semester results, reading up on new educational stuff, doing up new lesson plans, proactively assembling new exams/tests/assignments, etc.

It's one of those common fallacies that school teachers only work school hours and school days. The reality is slightly scarier.

It depends how they do it. If they've done it by making their additions a binary kernel module, they've not (clearly) broken the GPL.

Lots of vendors ship binary only kernel modules. Can you imagine how screwed up things would get if the courts ruled right now that binary kernel modules are considered as GPL tainted when loaded into a GPL piece of software?

The Wikipedia article points out that the German PBR was a prototype built in the late 60's and operational until the late 80's. A prototype. Built in an era where we were still getting a clue about this stuff.

Please use that article as an example of incorrect management/use of a prototype of an early technology that we need to evolve a little further. Same as any other early technology.

Instead, read this report, linked off of the Wikipedia article:

http://juwel.fz-juelich.de:8080/dspace/handle/2128/3136

That's a much more interesting read than the article.

ok, you win the internet tonight.

Because it's an open GL -reference- implementation.

No, the CCA (clear channel access) check is done at a signal level, not "can I decode this."

The problem with adjacent signal interference is that it doesn't necessarily appear as a solid, high signal level. It can appear like short, pulse like bursty interference in your receiver-on-a-different-channel.

CCA is supposed to be "I can't transmit at the moment because there's _some_ signal present above -X dBm." It feeds into the general air contention and exponential backoff stuff that should be done - ie, the air has to be continuously clear for all that time before the device starts transmitting.

Yeah, this stuff is complicated.

No, RTS just relies on nodes being able to see each other.

The problem with RTS is the standard hidden node problem. If you have two APs that can see each other, then any RTS each sends to a client will be seen by the other AP, which will back off. But, if clients can see all the other clients (and APs) then they can't hear the RTS being sent (or the CTS being replied); and thus they don't update their NAV.

Adrian

.. really? Yes there is. It's marginal but there is.

The point of having more channels means you don't end up with so much overlap, so the overlap you do have is at weak signal levels. But still, there's overlap.

It doesn't work as well as you'd like, when using omni-directional antennas. If you're using APs with those crappy metallic or printed antennas - heck, even a lot of laptops cheap out on the antenna design - you'll end up just dumping more energy into a crap antenna.

Hi. FreeBSD open source wireless developer here. I also work for a wireless company but this is all my own writing and is not endorsed or linked to my employer.

Don't do that. Let me repeat - don't increase TX power from what the card and regulatory limits say you can transmit.

Besides the regulatory limitations, the card may actually degrade if you increase the TX power. You may end up pulling more power than the card is designed or rated at. You may end up causing the output amplifiers to distort, which means you're not only breaking regulatory by spewing noise into adjacent channels, you're actually making your transmissions _worse_. It gets worse with higher transmission rates (especially 802.11n where the higher TX rates have much higher power density than the lower ones) - the Atheros driver implements per-rate TX power limits for this specific reason.

Chances are the manufacturer just has poor cooling, cheap part selection and all of that finely tuned RF front end is slowly degrading as a result. Buy an AP with better cooling or add better cooling yourself.

In fact, if you run the hardware at a _lower_ power output, you may find it lasts longer.