Contact
The best way to stay informed on our progress, is to keep an eye on this site. We will be releasing all updates, documents, source-code, and data here. Additionally, feel free to contact either of us to ask questions:
- Russell Senior: russell@unwirepdx-watch.org
- Caleb Phillips: caleb@unwirepdx-watch.org
March 29th, 2007 at 5:54 pm
What gear are you using to test the system?
How are your tests conducted?
Are you using a standardized test procedure?
How are your test locations selected?
How are you testing throughput?
March 29th, 2007 at 10:05 pm
> What gear are you using to test the system?
We used a Netgear WGT634U with OpenWrt. The stock radio is an Atheros. The txpower was set to 15dBm (~30 mW) to approximate a typical client device. It was mounted vertically near the top of a 1×2-inch hemlock “stick”, 6 feet long. The idea was to get the antenna above the height of our heads to avoid our inadvertently attenuating the signal as we moved around nearby. The GPS device which recorded our location was mounted at the very top of the stick. A USB hub and battery was mounted below the Netgear. The stick was taped to the handle of a 10×10-inch tamper to keep it upright without assistance.
> How are your tests conducted?
> Are you using a standardized test procedure?
The test procedure runs from a script. It tries to associate for at least 60 seconds, attempts to get DHCP 10 times, pings google to test connectivity, does a ping -c 10 to test packet loss, does get tests by timing wget’s of a 1 and 5 meg file, does a put test using ttcp. It does a few other informational things as well, such as save a copy of the arp table and performs a traceroute to a well-connected host.
> How are your test locations selected?
The testing RFP called for an assessment of the ability to get a connection in 90% of the outdoor areas in the POC area. We took that criteria very literally.
We took a simple random sample of 1000 points in a lat/long bounding box enclosing an area within 1000 feet of an active skypilot. We then excluded points that were more than 1000 feet from an active skypilot. Then we mapped those points against orthoimagery and excluded points that fell inside of buildings or landed in the river. This left us with about 483.
As we started, we were not certain how many locations we were going to be able to do (more being better, contiguous being better). Due to logistical concerns, the locations were not visited in order as would be ideal to maintain the randomness of the sample, but instead, initially, on a “what’s another location nearby” basis.
As soon as you start selecting which random locations to measure, it isn’t purely random any more. This is one of the things we are going to be looking at closely while preparing our report. As we were able to gauge how fast they were going, we were able to more efficiently target the low-numbered locations. We have a contiguous set for the first 25 locations, and the sparseness increases gradually as the locations numbers go higher. My sense is that there wasn’t much opportunity for bias. Of the “convenience locations” (higher numbered locations from our random set) that we’ve included in the preliminary analysis, we find a range of conditions: with/without line of sight, with/without vegetation, different distances from buildings, different distances from APs. My guess is that the results aren’t going to change much with a purely random sample. So, this is a weakness of our sample that we are aware of and will be addressing, possibly by collecting more data.
Some of the locations were inaccessible for one reason or another. In some cases they were in back yards. In some cases they were in the middle of the street. We tried to measure the exact location. But if we couldn’t, then if there was a reasonably nearby surrogate location (with similar distance and similar line-of-sight), we measured that.
> How are you testing throughput?
Upload speed was measured with ttcp. download speed was measured with timed wget’s of 1 and 5 megabyte files.
The testing RFP language is somewhat ambiguous in what constitutes a “connection”. The particular clause that describes the 90% coverage test doesn’t indicate was a connection is, however, a previous clause described a connection as 64kbps up and down, so we generally used that. We were somewhat liberal in our determination of what constituted a “connection”. If the ttcp put-test timed out (after 5 minutes), but the download test succeeded, we called that a connection.
March 30th, 2007 at 5:07 am
We recently tested the Portland MetroFi network and got results similar to what you have reported. Please contact me so we can discuss further.
Since we were not reponding to the RFP, we pick test locations very differently. We simply try locations within the advertised coverage area where people might actually want to use the service.
March 30th, 2007 at 4:13 pm
Some people have reported trouble in reaching the unwirepdx-watch.org email addresses. We may be having some kind of routing problem upstream. It works for me, so I am not sure exactly what the problem is. But, if those addresses fail, you can reach me at russell@personaltelco.net as well (which ought to take a different route that maybe works better). Sorry for the trouble!
March 30th, 2007 at 5:26 pm
And you can reach me at caleb@personaltelco.net.
June 1st, 2007 at 2:07 pm
Hello, Caleb:
I am really needing to uninstall the Metro-Fi Free on my iMac. It over-rides my cabel internet and then I can’t get connecred back into my cable internet except by unplugging my computer for several days at a time. The Metro-Fi Free is a product I would use with a laptop, but I regret letting it install on my home iMac. It popped up when I was having a weak connection one day on my cable, and thought, ‘O, Cool!’ Just isn’t working for me. Do you have instructions to assist me? Thank you, Dolly
June 1st, 2007 at 10:48 pm
Dolly,
If you are looking for technical support, I suggest you contact MetroFi for that. If that doesn’t work, you could try contacting the Personal Telco Project and asking them for help, but for problems with the MetroFi network, you should really be asking them.
http://www.metrofi.com/support_form.html
June 25th, 2007 at 12:45 pm
Interesting report, thanks for doing this. Too bad I missed the PLUG talk. Anyway, would you know how to get the lat/long for all the current MetroFi points? I do a lot of GIS mapping work, and it would be interesting to draw the 250′ buffer to show the theoretical dead spots, or to plot them in Google Earth to visualize line-of-sight issues. Did you go the GPS route because it was easier, or because MetroFi was uncooperative?
June 27th, 2007 at 11:35 am
Jim,
I am not sure how to get the lat/long for all the current MetroFi points, except to ask them. We started with the list of lat/longs provided in the Testing RFP that we had bid on. When we found that inadequate (because of some significant errors) we tried GPS and eventually used Google Maps to identify lat/longs most accurately. Furthermore, there were access points operating that were not included in the Testing RFP list. Even our survey from the late February drive testing was stale by the time we did our random location testing in late March, as new access points had subsequently been turned on.
I can’t say for certain that MetroFi would have been uncooperative, we didn’t ask them.
One difficulty in trying to use Google Earth is that line of sight is probably not accurate enough in that data. You will have issues not only of topography but also of buildings and vegetation. The standard in the Testing RFP did not consider line-of-sight, so we didn’t either.