New WiFi Protocol Boosts Congested Wireless Network Throughput By 700%
MrSeb writes "Engineers at NC State University (NCSU) have discovered a way of boosting the throughput of busy WiFi networks by up to 700%. Perhaps most importantly, the breakthrough is purely software-based, meaning it could be rolled out to existing WiFi networks relatively easily — instantly improving the throughput and latency of the network. As wireless networking becomes ever more prevalent, you may have noticed that your home network is much faster than the WiFi network at the airport or a busy conference center. The primary reason for this is that a WiFi access point, along with every device connected to it, operates on the same wireless channel. This single-channel problem is also compounded by the fact that it isn't just one-way; the access point also needs to send data back to every connected device. To solve this problem, NC State University has devised a scheme called WiFox. In essence, WiFox is some software that runs on a WiFi access point (i.e. it's part of the firmware) and keeps track of the congestion level. If WiFox detects a backlog of data due to congestion, it kicks in and enables high-priority mode. In this mode, the access point gains complete control of the wireless network channel, allowing it to clear its backlog of data. Then, with the backlog clear, the network returns to normal. We don't have the exact details of the WiFox scheme/protocol (it's being presented at the ACM CoNEXT conference in December), but apparently it increased the throughput of a 45-device WiFi network by 700%, and reduced latency by 30-40%."
"We don't have the exact details of the WiFox scheme/protocol, but apparently it increased the throughput of a 45-device WiFi network by 700%, and reduced latency by 30-40%." And what makes this different than Quality of Service (QOS)?
Sounds like they're messing with 802.11 CSMA/CA min channel idle time and backoff on the AP to boost its transmit priority (and probably also force RTS/CTS handshaking when there's too many collisions between client transmits).
Neat idea, but not exactly new. Plenty APs optimized for WISP usage do this already.
Maybe the novel part is in dynamically determining congestion level or something...
I'm guessing this works to solve temporary channel congestion issues, and not over-subscription (to which the only real solution on my opinion is to get a bigger pipe at the over-subscription point). My guess is that they keep buffers for each of the host associated with the AP, and when one of the buffers begins to get to some relative threshold they ignore the RTS frames from the other stations and allow said buffer to clear to some min point before sending a CTS to the other stations.
If all of your associated host are simultaneously trying to send data in a full-mesh (all hosts talking to all hosts), I don't see how this would alleviate spectrum congestion (and you would think in this scenario latency would go up if they are round-robin'ing the queue clearing).
Implementation details would be sweet. To me this sounds like ETS queuing/COS as seen on enterprise wired L2/L3 switches. Have to wonder if there is any RED/WRED when queues reach max size? Speculation....
'We are trying to prove ourselves wrong as quickly as possible, because only in that way can we find progress.' RPF
Is this the same as last months "breakthrough" technology described in the MIT technology review.
http://www.technologyreview.com/news/429722/a-bandwidth-breakthrough
That breakthrough uses special coded TCP secret technology only known to the select few who sign the NDA. The rest of us have know it since 1951 as Hamming Codes, or more recently Forward Error Correction.
How about combining it with this technology from an earlier slashdot story: http://hardware.slashdot.org/story/12/10/23/1946248/increasing-wireless-network-speed-by-1000-by-replacing-packets-with-algebra
Sounds like this is based on the simple fact that most internet clients are consumers of data, not producers (high download to upload ratio). So if you make the access point more bossy, to the point of no longer playing nice and waiting its turn to transmit (thus it will be transmitting over the other devices in this mode), the overall result is more efficiency when moving larger amounts of data.
This makes sense on a number of levels. There is no point in letting client devices waste airtime requesting more data (again, assuming they are primarily consumers of data) when there is already a backlog of data that needs to be pushed down the pipe. Additionally, access points are centrally located and have higher gain antennas, thus even when they "double" with another device, there is a good chance that the recipient device will still be able to "hear" the access point over the other devices.
So I can see how this "high priority mode" would work, even if the formal protocol doesn't support it (ie the client devices can be totally stock). It's like being in a room full of people talking, and instead of waiting for people to quiet down to tell a friend across the room something, you simply start yelling. They are able to hear you because you're louder (higher gain antenna), and the other people don't have to quiet down either (since they're just talking).
There would likely be problems with this scheme when multiple access points have overlapping coverage - there would be lots of collisions at the fringe areas where they overlap. It would also have problems when someone is performing a large upload at the same time someone is streaming data down, because the access point would keep turning a deaf ear to the uploader. Also, if you had two clients sitting side by side, then that extremely close proximity could result in too strong of a client / client signal that the access point couldn't overcome.
Better known as 318230.
Like it was/is sometimes used in ham-radio packet radio or in satellite communitation.
http://en.wikipedia.org/wiki/Demand_Assigned_Multiple_Access
The wikipedia description actually makes it sound a bit more complex than it actually it. In packet-radio DAMA simply meant that the central station polled each node regularly and asked it if it has queued requests. The only thing a client was allowed to send without asking back was the "I am a new client"-message.
Idiot is a verb now?
Just of its own clients and other stations that can hear it. Some packets will potentially be lost due to the hidden-transmitter problem.
Bruce Perens.
Idiot a fucking dictionary, noob.
Idiot a fucking dictionary, noob.
Fuck you and the horse you idioted in on!
Makes it sound like 700% gains are for everyone in the network. So we're to believe that occasionally discarding the buffered requests of a large subset of users magically solves a persistent congestion problem where more bandwidth is being demanded than is available? I suspect there will be a few happy users (who received priority) along with lots of sad faces.
This is the engineer-speak version.
Sales speak: "We can slash the R&D budget to nothing for the next 5 years by selling existing hardware with incremental improvements to the software stack, maximising our likelihood of getting a brand new Audi every six months. We should probably put a new fridge in the break room, though, so the peons don't get pissy about us shafting the consumer and not giving them a pay rise for the third year running."
Finally had enough. Come see us over at https://soylentnews.org/
Use an ethernet cable if you're at home. Faster AND more secure. Ok , you can't if its a smartphone or an ipad but I'm talking about when using proper computers, not toys.