Showing posts with label WiFi Tech. Show all posts
Showing posts with label WiFi Tech. Show all posts

Saturday, March 5, 2011

Stop Watching Me!

The wireless watchdog from the last post was short lived, as the data it sent back made a clear case for changing the wireless configuration (it also had some annoying side-effects on the link).

The link in question is firing through some foliage (if you know the guy with the trees, please ask him to cut the tops off :)), and wind seems to be having the effect of causing the signal to levels that disconnect the STA.  As a more permanent fix, we switched the link to ADHOC mode, which limits some of our HT options, but seems to fix the stability problem while still giving us link speeds near the peak speed of the uplink.  


It's funny, you can totally see the trees waving in the breeze in the ping times:

64 bytes from 10.100.0.218: seq=295 ttl=64 time=1.172 ms
64 bytes from 10.100.0.218: seq=296 ttl=64 time=719.076 ms
64 bytes from 10.100.0.218: seq=297 ttl=64 time=1.207 ms
64 bytes from 10.100.0.218: seq=298 ttl=64 time=1.805 ms
64 bytes from 10.100.0.218: seq=299 ttl=64 time=425.842 ms
64 bytes from 10.100.0.218: seq=300 ttl=64 time=2.308 ms
64 bytes from 10.100.0.218: seq=301 ttl=64 time=6.422 ms
64 bytes from 10.100.0.218: seq=302 ttl=64 time=1.321 ms
64 bytes from 10.100.0.218: seq=303 ttl=64 time=2.304 ms
64 bytes from 10.100.0.218: seq=304 ttl=64 time=23.272 ms
64 bytes from 10.100.0.218: seq=305 ttl=64 time=1.172 ms
64 bytes from 10.100.0.218: seq=306 ttl=64 time=7.758 ms
64 bytes from 10.100.0.218: seq=307 ttl=64 time=21.644 ms
64 bytes from 10.100.0.218: seq=308 ttl=64 time=13.355 ms
64 bytes from 10.100.0.218: seq=309 ttl=64 time=9.076 ms
64 bytes from 10.100.0.218: seq=310 ttl=64 time=281.356 ms
64 bytes from 10.100.0.218: seq=311 ttl=64 time=1.200 ms
64 bytes from 10.100.0.218: seq=312 ttl=64 time=302.242 ms



Despite the high jitter, there's no packet loss at all on the link.  Hurray for greenfield deployment!

Thanks to our new clients for their patience while we sorted this one out.  I expect that the quality of the link should be much improved going forward. 

Thursday, March 3, 2011

Watch Me!

It's been a long week of updating wiki pages and building firmware to clean up all the loose ends from January and February. A big data dump is coming soon, but to tide you over here's a little techie interlude...

As I may have mentioned before, we added infrastructure mode wireless connections to our config options to capture HT throughput (the adhoc HT driver is coming! I can practically taste it). While AP / STA can be fast, it also adds the whole complication of association. In greenfield environments, the noise floor is generally so low that we can run fast links with scary-low signal strengths (the floor on the link budget is often device sensitivity, not noise at all). In adhoc mode that works great, but in infrastructure mode, there's some setting I haven't found yet that keeps a device from reassociating with a link that's running below a certain strength (or maybe a limit on the number of reassocs, I'm not sure).

In any case, devices dropping links that are perfectly good has been an issue lately, but it seems bumping the AP's wireless connection is enough to get it back, but we can't just sit there waiting for the connection to go down?  Or can we?  Enter watchdog (details truncated for brevity):

#!/bin/sh
while true
    do
    resp=""
    resp=`iw dev wlan0 station dump | grep -c "[MAC you care about]"`
    if [ $resp == 0 ]
        then
        wifi
        echo `date` No assoc. bump wifi >> /tmp//log.log
        sleep 10
    fi
    sleep 5
done

It's not the ideal solution, but seems to be working so far.  And I'm not one to screw with what works...

Monday, December 21, 2009

Beating the Multi-Hop Routing problem (or not)

Most of those familiar with wireless meshing are familiar with the multi-hop wireless problem. For those unfamiliar with the space, the problem is simple: A radio has a fixed maximum bandwidth (for 802.11g it's roughly 22Mbps of half-duplex real throughput). Any time a device needs to receive and forward data over the same radio, it must share this bandwidth between sending and receiving, meaning that after four or five radio hops there is precious little bandwidth left. (for the first hop, the bandwidth hit is roughly 50%, I haven't tested what happens after that, but one would expect the proportional degradation per hop gets less severe as the signal thins out) At any rate, the multi-hop problem is a major issue in a region-scale wireless network with sparse or distributed network resources, and since FabFi is going to be HUUUUGE, I set about some experiments to see how one might beat it.

The bandwidth halving over multiple hops is fundamentally a physics/hardware problem. A single radio cannot send and receive at the same time, and no two radios can talk on the same channel at the same time. Two radios can, however, talk at the same time on non-overlapping channels--theoretically--begging the question, if every device had two radios, would we be cool?

Sadly, not so much...

A little bench testing with four routers yields the following (I believe these numbers are full-duplex, so x2 accordingly for what you would expect the numbers to be...)
  • setup 1: Single-hop cabled , 24.3 Mbps
  • setup 2: Multi-hop cabled, 24.2 Mbps
  • setup 3: Single-hop wireless, (ch11) 11.4 Mbps
  • setup 4: Multi-hop Radio-cable-radio (close quarters, directed, ch 1., 11) 5.82 Mbps
  • setup 4b: Multi-hop Radio-cable-radio (close quarters, ch 1., 11) 5.81 Mbps
  • setup 5: Multi-hop Radio-cable. (ch 11) 11.5 Mbps
  • setup 6: multi-hop Radio-cable-radio (30', ch 1, 11) 10.8 Mbps
(same physical setup as above, but with different channel selections)
  • setup 6b: multi-hop Radio-cable-radio (30', ch 1, 6) 15.4 Mbps
  • setup 6c: multi-hop Radio-cable-radio (30', ch 1, 5) 12.2 Mbps
  • setup 6d: multi-hop Radio-cable-radio (30', ch 13, 9) 11.2 Mbps
  • setup 6e: multi-hop Radio-cable-radio (30', ch 1, 4) 6.54 Mbps
  • setup 6f: multi-hop Radio-cable-radio (30', ch 1, 3) 5.39 Mbps
  • setup 6g: multi-hop Radio-cable-radio (30', ch 1, 2) 6.98 Mbps

Background, for reference:
From the above, it is clear that a multi-radio 2.4GHz device is unlikely to have the desired effect of radio-radio hopping without bandwidth degradation unless the physical radios are fairly far apart. It is, however feasible to achieve bandwidth preserving multi-hop routing over the radio with two wireless devices separated over a wired LAN, suggesting that there might be a benefit to modifying the OLSR protocol and channel selection algorithms to take advantage of this situation when it arises in the wild.

As an aside, the above also suggests that in a crowded RF environment, spreading devices across all 13 wifi channels, using ch 1, 5, 9, and 13 is nearly as bandwidth-preserving than the traditional 1, 6, 11 configuration. Channels closer than four apart interfere with each other almost completely, even at a modest distance from each other.

Sunday, September 27, 2009

Mesh Channel Selection

There's been a lot of discussion about how to select wireless channels in JBad. As anyone reading along will notice, it's getting really crowded up on the water tower (nine downlinks) to the point where it's important to worry about airtime on the radios:

A standard wireless router has 11 available wireless channels. Of these 11, only three are completely non-overlapping (ie: can talk at the same time without interfering with each other).

In our implementation, no two nodes can communicate unless they're on the same channel. In short, this is because if they could, eventually everything would end up on the same channel, which we don't want. In terms of OLSR this is important, because if two nodes are on separate overlapping channels, they will interfere on each other's transmissions if they try to talk at the same time, but will ignore each other's RTS CTS messages, so they won't ever coordinate. As a result, you get crappy throughput if you have two busy nodes on, channels 5 and 6 right next to each other.

In our implementation most of the downlinks on the water tower were channel 6. We then deployed a pair on channel 5, and despite good signal were seeing an ETX of 4.5 instead of the < 1.1 that we would expect for a link of this quality. Switching the channel to 6 brought the ETX down to 1.05.

Take Home:

Wireless channels must be either the same or non-overalpping for any nodes in your network that can hear each other.