Sunday, December 28, 2008

Thinking about performance today... I want to get double the throughput we're getting right now. Note the numbers we've been posting are not link speed, but actual data throughput, so don't compare to the 54Mbps number you see on the side of the box your wireless router came in. 54Mbps links only get about 22Mbps throughput before adding outside-the-protocol optimizations.

Friday, December 26, 2008

Today Kerry and I set off for a 3.17mi field test--a link longer than any we expect to make on this trip to Jalalabad.

First we determined that the AP->STA ping problem we had last time was a firewall issue on the router. For the moment, we just disabled the firewall by removing the S45firewall file from the /etc/rc.d folder on the STA and AP (though I suspect we only needed to remove it on the STA - will try later). For those who aren't familiar, the purpose of the files in this folder is to call startup scripts in a particular order (each file links to a file in init.d). By removing S45firewall, we kept the firewall from booting, leaving the link wide open.

With that issue solved, we moved to the field and I found this beautiful spot at the fells end of the 3.17 mi link:pointing at the wrong parking lot... I guess I only know my way around in the dark. It wasn't long before I realized my mistake and shuffled over to the southwest side of the fire tower for this setup, pointing the right way:We then proceeded to make links with both the small and large reflectors, seeing a -70 dB signal strength with the large reflector and -82 dB with the small. Extrapolating from the signal strengths at 2.17 mi, the ideal expected signals would be -67 dB and -79dB, respectively, but our line of sight was much narrower on this link and there was more moisture in the air than on the last test.

Initial throughput tests for the large reflector yielded .58 Mbps. After setting the

option distance 5200

setting in /etc/config/wireless (same section as the channel), our link speed improved to 2.62 Mbps (x5!!). Switching to the small reflectors, we recorded a throughput of .79 Mbps, suggesting lots of packet loss--plenty worse than the ideal case numbers I posted here--maybe this is a result of the WiFi Signal a couple channels over? (see trace below)

Below is a trace from the Wi-Spy on the big reflector during the throughput tests. You can distinctly see the (local) STA and (remote) AP.

We attempted to get a reading on the Wi-Spy by adding a second STA on the AP side and sending data to it as mentioned in the last post. Note, to add a STA you need to add a route to it on the AP. Kerry added the following route to the boot section of /etc/init.d/network. New STA is .133.1, AP is .127.1:

route add -net 192.168.133.0 netmask 255.255.255.0 gw 192.168.127.3

though it can probably be added to /etc/init.d/custom-user-startup and have the same result. At any rate, our three router scheme didn't work as planned, as we didn't see anything on the other end of the link. More testing is required in a controlled setting. A complete set of the config files on the STA and AP for this test can be found here

A final interesting tidbit: the Motorola Talkabout radios worked passably over this distance when mounted in the reflectors. This is 1.5-3x (I have two models) their intended range.

Improved backpack selection made heaving 40 lbs of gear up the hill much more comfortable, BTW:

Tuesday, December 23, 2008

Kerry an I went out to try the 54GLs in their first long-range link. There was some apprehensiveness about this test due to the fact that the transmit power of the 54GLs is not as high as the other linksys router model we use [insert model here]. The foot of snow didn't help either, but we forged on.

For the test, we used the 2.17mi link we scouted a couple weeks ago. Kerry set up on top of the parking Structure at Alewife Station, and I hiked the other half of the link out to Robbins Farm in Arlington. Here's the setup:

The image on the left is the 54GL on the small reflector, and the one on the right is the old Linksys AP on the large reflector. Note how the routers are positioned to place the antenna in the focal point of the reflector. The whole thing looks like this

with the large reflector used as a base for the small one. Though this is convenient when you don't have a stand, I want to separate the two in future tests to be sure that the large one isn't increasing the performance of the small.

After aiming the antennas visually (the straw-scope [insert pic] works well for this purpose) we fired up the Nighthawk and took a look with the wi-spy. For the small antenna we got the following data. All measurements are at the 2414MHz:

-90.0 dB (noise threshold was -102.5 dB, avg)

No significant effect when aiming at a point 100m off-axis

For the big one [link this to big antenna design page. It's the first time it's mentioned] we recorded:

-86.0 dB (noise threshold was -97.4 dB. avg)

No significant effect when aiming at a point 100m off-axis

Here's an example of that the camera's RF signature looks like at -90 dB. The signal is centered at 2414MHz:With the antennas positioned, we started up the routers, and after getting the antennas selected correctly, we made strong links with both router models on both antennas. Using the

wl rssi

command on the STA router [Add link to network diagram, when ready], we saw signal strengths of -63 dB on the big antenna and -74 dB with the small antenna using the 54GL. We used a network analysis tool called NetPerf to test network throughput (go here for the winXP binaries we used. I have no idea what version of NetPerf they are.) following these steps:

Start a command prompt window on a PC at one end of the link and start netserver like this:

netserver.exe -p <port>

We used port 7777.

Run net client on a PC at the other end of the link by opening a command window and calling:

netclient.exe -p <same port> -H <IP of netserver PC>

Note: You must be able to ping the netserver machine from the netclient machine. The reverse does not seem to be required as Kerry, who was at the AP, could not ping my PC at the STA but I could ping his PC at the AP and we could only get netclient to run successfully on his machine.

Also note: every time netclient is run, netserver must be restarted.

Throughput results, surprisingly, were better for the 54GL than for the older, more powerful router, and tests with both reflectors performed returned similar results in terms of throughput. The complete results were:

Silver Router:

Big Reflector - .73 Mbps

54GL

Big Reflector - 1.30 Mbps

Small Reflector - 1.25 Mbps

Note that the "option distance" setting was not set in the wireless config file for these tests. We will try to determine if setting it has any effect on throughput during the next test. The configuration files that were modified from their default values for this test are here.

Overall this was a successful outing. We are now confident that the 54GLs will work, and have already met our minimum test distance for the Afghanistan trip. On friday or saturday we'll try the 3.17 mile link, and possibly shooting through trees.

Helpful tweaks for next time:

Install "wl" utility on the silver routers so we can directly compare signal strengths between the two models

Investigate ways to test the signal strength of the router directly in the event a connection cannot be made. Possible idea: bringing a 2nd STA into the mix at short range. because the firmware keeps the tx power pinned at 19dB, we should be able to talk to a second AP at short range and then read the signal at the other reflector as if we were trying to talk across the link.

Troubleshoot pinging PC-PC in the AP->STA direction

Write up a more complete test plan before going out to make sure we don't forget anything or waste time.

Taking the advice of the Wi-Spy site, we purchased a Swann Nighthawk 2.4GHz wireless camera for the purpose of aiming our reflectors. The beauty of this little gadget is twofold. First, it has a very distinctive RF signature, so it's easy to see on the Wi-Spy. Second, it has a spectacularly awful antenna, so you don't have to get too far away from it before you can tell the difference between the Nighthawk all by itself and the Nighthawk with some sort of augmentation.

In today's field test, the goal was to use the Nighthawk to give some indication of the gain of our small reflector [link to design site for small reflector to be inserted] and its sensitivity to aiming. We took measurements from the nighthawk at distances of approximately 85m and 250m both with and without the reflector attached.

tx setup:

rx setup:

The big black thing is an LCD panel that displays video from the camera. In our testing, we were able to roughly position the reflectors based on the video quality, though the Wi-Spy is much more precise.

Here's an example of the RF signature from the Nighthawk as seen by the Wi-Spy:

And the results:

The gain numbers are very encouraging. I would hypothesize that the gain for the short link (and for off-axis shots) is inflated by the narrow corridor of tall buildings we were testing in, but the gain for the long link (~18.6dBi, on-axis) is definitely within the realm of what commercial antennas advertise. By the numbers, that level of gain could take us over 5 miles with the 54GLs in the right conditions, though it will probably be less in vivo.

Wednesday, December 17, 2008

In preparing for a field test, I wanted to try a couple of different antennas I had lying around, but the WRT54Gs have a really annoying antenna connector (RP-TNC), which is not the one nearly every other commodity wifi Product uses (RP-SMA), and not what more professional grade antennas use either (N-Type). Suffice to say some adapters are on order.

You can input these commands in the CLI, and see their results in real time, but to make sure they are set correctly every time you start up, add the select commands to "/etc/init.d/custom-user-startup" like so (input 0/1/ 3 as desired):

wl txant 0wl antdiv 0

To listen to the results of turning the antennas on and off on the STA, I'm using both the wi-spy and the

wl rssi [macaddr]

command on the routers. Note, the macaddress specified in the etc/config/network configuration file is not what the AP sees. I can't figure out where this macaddress is specified (Kerry, input?), but you can use

wl dump

to identify the current macs for all interfaces on the STA. In this case you care about

perm_etheraddr

I'm not sure why...

Since you know there is only one associated STA on the AP, you can also use

wl assoclist

to return the mac of the STA.

I was curious if the antennas on the 54GL were equally powerful. Not knowing anything a-priori about how they were constructed, I set up an experiment like so:

Both antennas are removed from one router (not in pic), and both are attached on the other. By removing the antennas from one router, I am able to clearly differentiate the two devices in the Wi-Spy readout. By switching the tx/rxant setting on one device while leaving tx/rx set to a constant antenna on the other, I was able to assess the relative tx power of antenna 0 (left) and 1 (right). In order to push a lot of data and get repeatable readings on the Wi-Spy, I hacked up a little ping program that lets me send a lot of really big ping packets really fast. You can download it here.

Right:Left:According to the traces, the right antenna is considerably stronger than the left. When using only the left, the roter even switched to 802.11b mode (this is the expected behavior when the signal goes below a certain level). Upon consulting Kerry, the results make sense, as the internal wiring to the left antenna is considerably longer in the 54GL (and all of the Gs, presumably).

We'll use the right antenna (setting 0) in our setup then...

FYI this page has a good list of config values. One of which is "distance". Could this be a catch-all wrapper for the timing issues we expect to face?

Monday, December 15, 2008

First off, it is useful to install the "wl" package on the router. It has a lot more commands than wlc, and is the only way to adjust transmit power as far as I can tell.

Max transmit power is supposed to be 84mW = 19.24dBm, though when using the configuration tool like so:

wl txpwr

The device outputs:

pwr in mw 127pwr in mw after override adj 1271496

The values are mislabeled here, and are actually qdBm. But you can still set to max value like this:

wl txpower 1496

Also, "txpwr1" outputs more readable values and lets you set in dBm. I tested the two extremes with the Wi-Spy (a nifty USB network Analyzer), and saw a modest difference between the two settings. Look at the strong signal on channel 3 (screen captures are from the Chanalyzer 3.2 software - free from MetaGeek).

txpwr = 1:txpwr = 1496:Though the difference between the two power levels was not particularly obvious, it was very repeatable. there's an 802.11b signal at this level as well, but has nothing to do with us.

[EDIT: there is a bug in the openWRT firmware that prevents the power from being set to anything greater than 19dBm, even though we set the value at nearly 32dBm. This may get fixed in the 8.09 version of OpenWRT]

Also note: The weaker 802.11g signal on ch3 is the another WRT54GL with the antennas removed. Both routers are the same distance from the Wi-Spy. (about 3ft in this case)

Like many developing countries, Afghanistan's basic infrastructure (roads, sewers, power grid, communications) is largely damaged, unmaintained or non-existent. Such lapses in infrastructure leave the country physically, economicaly and socially fragmented. While it is difficult for individuals to buld roads, string power lines or dig sewers to bridge existing gaps, meshed wireless data networks can allow individuals to build communication one link at a time.

The goal of the FabFi project is to lay groundwork for a user-implemented, locally-grown wireless community. Through FabLab Afghanistan, the FabFi team will train an initial cohort of local users capable of standing up wireless links using readily available materials. These users will gain valuable technical skills, opening up new economic opportunities to them and preparing them to lead a wave of viral network growth.

It is our hope that the FabFi infrastructure will quickly grow to support a vibrant, interconnected community whose users share ideas and learn from one another.