Thoughtful, detailed coverage of the Mac, iPhone, and iPad, plus the best-selling Take Control ebooks.

 

 

Pick an apple! 
 
Keyboard Shortcuts in Stacks

You aren't limited to using the mouse or trackpad to select items within a stack. Once you've clicked a stack to open it, you can type a letter to jump to the first file starting with that letter, or press either the Tab or arrow keys to move among the stack's contents. Press Return to open the selected item.

Visit plucky tree

Submitted by
cricket

 
 

Testing the TCPL's New Wireless Network

Send Article to a Friend

A few days ago I went down to the Tompkins County Public Library with Tonya, Contributing Editor Mark Anbinder, and our technical friends Keith Kubarek (a consultant who helped us decide on a content management system) and Oliver Habicht (an IT director at Cornell University Library) to test their new wireless network. It's not quite public yet, but Michael Salm of Sherpa Technologies, who had installed the network, wanted to have a few people bang on it before the library started the training, publication, and PR tasks necessary before opening it to the public.

<http://www.tcpl.org/>
<http://www.sherpatech.com/>

Michael had installed a Cisco Aironet access point with an omnidirectional antenna to serve almost the entire public area of the library (it's in a nicely remodeled department store that was occupied by Woolworth's the entire time I was growing up; the public area is a mostly open space on the main floor, as you can see at the photo gallery link below). Initially, I was slightly dubious that we would be able to provide any useful feedback; after all, my experience of wireless networks is that you plug in the access point, set a few options, and it all just works. Indeed, after Tonya and Tristan (who got huge points for spending the entire time drawing and looking at the art in a massive book on naval history) and I walked in, I pulled out my PowerBook, opened it up, and was immediately greeted with a dialog asking me if I wanted to add the library's network to my list of trusted networks. A click or two later and Cornell's weather forecast Web page appeared, telling me that there was a severe thunderstorm watch until 8:00 PM. (It's been one of those summers.) I showed everyone the page, announced, "Our work here is done," and mimed leaving.

<http://www.tcpl.org/photogallery2.html>

Nonetheless, the real testing that ensued proved to be extremely valuable. The library has long allowed patrons to connect their laptops to Ethernet jacks to access the Internet, and Michael has locked that access down to allow only Web and email access. That's not entirely unreasonable - we're talking about a library here, with potentially many people sharing a single pipe to the Internet, so it's smart to restrict high bandwidth uses and things that could cause a liability (peer-to-peer file sharing in particular). Michael's good sense in having us test things was proven quickly, when we determined that FTP wasn't available, that SSL email to Cornell didn't work, and that other Cornell authenticated services couldn't get through the firewall. Michael bustled off to open those ports so Keith could make changes to his Web site via FTP and Mark could check his Cornell email (in the end, Mark was able to check Cornell email via the Web, but Michael is still working on enabling the Cornell-specific services).

As an aside, when the initial discussions about installing a wireless network were underway, there was concern on the part of the library that the wireless network might prove a security risk or other liability, and should perhaps have its access restricted or time of operation limited in some way. When we looked into how the wireless network would tie into the library's wired network, however, we realized it wasn't appreciably different from what was already possible with patrons connecting their laptops to the Ethernet jacks. The public part of the network was separated from the library's intranet, and the firewall served both to reduce the likelihood of most abuses and to log any suspicious activity. It seems highly appropriate that the library, an organization whose mission it is to promote learning and information sharing, ended up with a reasonably open network that doesn't require usernames or more draconian measures.

Next we wandered around the far-flung corners of the library building, testing signal strength. For reasons we still don't understand, Keith's Titanium PowerBook G4 showed much higher numbers for signal strength in MacStumbler (70 to 90) than my 12" PowerBook G4 did (30 to 60), but his copy also reported high noise numbers (55), whereas my copy displayed the noise rating at 0 the entire time. I suspect there's something related to the fact that my PowerBook uses AirPort Extreme (802.11g), whereas Keith's uses AirPort (802.11b). Tonya's white iBook, also using AirPort, showed even higher signal strength numbers than Keith's Titanium PowerBook G4 (not surprisingly - the iBook is a stellar performer when it comes to range), but also reported 55 for noise. I also tried a slightly old version of iStumbler, which reported very similar numbers, making me think they're coming from the AirPort driver.

<http://www.macstumbler.com/>
<http://www.istumbler.com/>

Amusingly, during the signal strength test, we discovered a couple of other wireless networks, a closed one that we knew was run by another organization that shares the library's office space, and another called "UBWireless" that we were never able to triangulate or identify beyond its name. These days, such overlap of wireless networks is common, so it's always worth checking to make sure channels don't interfere. Whatever UBWireless was, it was using channel 1, and since the Cisco access point had automatically chosen channel 3 (probably before the UBWireless network appeared), there could have been some interference. Luckily, it's trivial to change channels to avoid such conflicts.

After determining that the connectivity to the Cisco access point was fine, we settled down to test throughput. Although we only had six or seven devices, we figured we could artificially load the network to see how it performed under stress. A number of people started playing Apple's QuickTime movie trailers (with the volume down - it is a library!), and I sent Interarchy off to download a huge file from our Xserve, which can normally serve that file to me at over 80K per second on my 1 Mbps long-range wireless connection at home. The download started slowly, and in general, responsiveness to the Internet was not as perky as we would have liked. I tried using the Link Rate tool in Sustainable Softworks IPNetMonitor X to learn more, but since it relied on ICMP pings to monitor round trip time, it couldn't get through the firewall.

<http://www.sustworks.com/site/prod_ipmx_ overview.html>

That's when I remembered that Interarchy 7 has network monitoring tools as well, so I pulled up its Network Status window, which displays a graph of incoming and outgoing traffic over time. It showed that I was getting only 20K to 30K per second transfers, with the occasional spike up to 192K per second and dips down to under 10K per second. That seemed slow, given that the library has a 2 Mbps wireless connection to the Internet, even though that connection was being shared with all the library's public Internet terminals and the other testers.

<http://www.interarchy.com/>

We backed off our testing, and determined that it wasn't related to what we were doing, since the problem was still there when only one of us was downloading. Then I plugged my PowerBook into the wired network and tried again. The wired test produced the same result, implying that the problem probably didn't lie with the wireless network at all, but with the 2 Mbps connection to the Internet. Michael was concerned with that result, needless to say, but it was a task for another day, since as far as we could tell, the internal wireless network was working well. At that point, our work really was done, so we closed up the laptops and went off to dinner.

The moral of the story is that independent testing is always important, since it can turn up problems you didn't anticipate, even in seemingly unexpected parts of the system.

 

READERS LIKE YOU! Support TidBITS by becoming a member today!
Check out the perks at <http://tidbits.com/member_benefits.html>
Special thanks to Carl BĂ©liveau, David Robertson, Jose Vargas, and
Kevin Kemball for their generous support!