March 2004 Archives

Mobile Blogging with the Treo 600

|

     I've been looking for a blogging app for my Treo for such a long time that I eveentually gave up, thinking that I was the only one interested in such a thing... Well, thanks to a comment by Jeff Jarvis, I think I found it - Vagablog. If you are reading this, it even works. (I ended up having to reconfigure a few things with my weblog, but it does, indeed, work!)

     After the adventures of Saturday, I have been able to take some time to learn more about tweaking the Feed and the Center. Located at the Feed, I have a Proxim MP.11 Subscriber Unit and at the center, I have a MP.11 Base Station (also known as an SU and BSU). Most of the clients will end up using a Residential Subscriber Unit (RSU) because of a) cost and b) lack of need for the one feature that differentiates it from the SU - unlimited MAC address association. The Center is broadcasting using a 15.5 dBi omni directional antenna about 55 ft in the air and the Feed is transmitting using a 15 dBi directional patch antenna (with a beam width of about 30 deg.) located about 40 ft. off the ground. One of the potential clients of the system asked about network latency... I hadn't actually put much thought into it until the question was asked! How will the environmental and setup factors effect network latency? This is especially important as the system grows. If I have drastic latency issues right now, I can only imagine them getting worse as more users come online.
     To begin simple latency tests, I took a workstation behind the feed-node and pinged the center-node. The results look a lot like:

bash-2.05b$ ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1): 56 data bytes
64 bytes from 10.0.0.1: icmp_seq=0 ttl=64 time=157.648 ms
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=72.399 ms
64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=24.191 ms
64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=5.961 ms
64 bytes from 10.0.0.1: icmp_seq=4 ttl=64 time=6.612 ms
64 bytes from 10.0.0.1: icmp_seq=5 ttl=64 time=6.525 ms
64 bytes from 10.0.0.1: icmp_seq=6 ttl=64 time=6.662 ms
64 bytes from 10.0.0.1: icmp_seq=7 ttl=64 time=14.702 ms
64 bytes from 10.0.0.1: icmp_seq=8 ttl=64 time=6.383 ms
64 bytes from 10.0.0.1: icmp_seq=9 ttl=64 time=6.441 ms
64 bytes from 10.0.0.1: icmp_seq=10 ttl=64 time=64.546 ms
64 bytes from 10.0.0.1: icmp_seq=11 ttl=64 time=16.346 ms
64 bytes from 10.0.0.1: icmp_seq=12 ttl=64 time=6.614 ms
64 bytes from 10.0.0.1: icmp_seq=13 ttl=64 time=6.834 ms
64 bytes from 10.0.0.1: icmp_seq=14 ttl=64 time=6.490 ms
64 bytes from 10.0.0.1: icmp_seq=15 ttl=64 time=110.844 ms
64 bytes from 10.0.0.1: icmp_seq=16 ttl=64 time=27.913 ms
64 bytes from 10.0.0.1: icmp_seq=17 ttl=64 time=6.147 ms
64 bytes from 10.0.0.1: icmp_seq=18 ttl=64 time=167.393 ms
64 bytes from 10.0.0.1: icmp_seq=19 ttl=64 time=84.476 ms
64 bytes from 10.0.0.1: icmp_seq=20 ttl=64 time=162.557 ms
64 bytes from 10.0.0.1: icmp_seq=21 ttl=64 time=79.655 ms
64 bytes from 10.0.0.1: icmp_seq=22 ttl=64 time=31.363 ms
64 bytes from 10.0.0.1: icmp_seq=23 ttl=64 time=69.290 ms
64 bytes from 10.0.0.1: icmp_seq=24 ttl=64 time=37.645 ms
64 bytes from 10.0.0.1: icmp_seq=25 ttl=64 time=6.147 ms
64 bytes from 10.0.0.1: icmp_seq=26 ttl=64 time=6.734 ms
64 bytes from 10.0.0.1: icmp_seq=27 ttl=64 time=6.072 ms
64 bytes from 10.0.0.1: icmp_seq=28 ttl=64 time=6.550 ms
64 bytes from 10.0.0.1: icmp_seq=29 ttl=64 time=15.885 ms
^C
--- 10.0.0.1 ping statistics ---
30 packets transmitted, 30 packets received, 0% packet loss
round-trip min/avg/max/stddev = 5.961/40.901/167.393/49.723 ms

As you can see, there may be wild variances in the round-trip time, but for the most part, the feed to node round-trip time is around 6ms. At first I was quite a bit concerned about the fluctuations - in fact, I still am concerned, but it is a reality of the OS on the equipment and the environment. Another thing that one should notice is that it will maintain a round-trip time of 6ms for a few pings and then jump to some double or triple digit number. In my estimation, this is partly due to flex of both of the antennas in the wind and reflection issues. One thing I have been reading about is background noise when using an omni. Eventually, if we got over 20 subscribers (which would mean that we would be setting up a ResNet - and is not the current goal of the project), I would consider sectorizing the center-node (i.e. breaking up the omnidirectional center-node and puting in directional patch antennas that cover a 60-120 deg. area instead of 360 deg.). On top of the environmental issues, a feature of the MP.11 series is SU/RSU registration polling periods. It appears that every 5 seconds, the SU/RSU re-registers with the BSU - which would be good reason for latency spiking at what appears to be 5 second intervals. I ran a ping test over night on Saturday and found that the cycle of jumps from 6ms to >6ms was extremely regular - again, every 3rd-7th ping.
     Another setting I toyed with was overall throughput settings - i.e. 11 Mbits/s vs. 5 Mbits/s, etc. I have found on other wireless systems that although a higher bitrate connection can be achieved, the signal strength is low enough that throughput at that bitrate is worse than if we were to simply go to a lower bitrate setting. I played with different combinations and found that the signal between feed and center is good enough that leaving it at 11 Mbits/s doesn't give me worse round-trip ping times than setting the BSU or SU/RSU at a lower bitrate. This may change, however, with the introduction of more SU/BSU's. Luckily, though, as long as the signal is decent, changing these settings won't impact the latency to any great extent.
     The literature is very vague concerning how to reduce latency issues. I think that the first objective of any project is to provide the access and then move on to improving network performance. I am surprised, however, that not much effort seems to be put into this issue - I don't know whether it is because of the apparent connection between signal strength ad latency (it appears that as the signal gets worse, the latency goes up - no surprise there - however, what is the threshold?) or whether it is simply a forgotten issue. I will continue to tackle the problem, however, as I add more end-nodes and see what system parameter changes I can make that will help reduce over-all system related latency.

Anywhere Technology: Center-Node & Feed Construction

| | Comments (0)

    Well, the project has begun and I feel good. We have a link up between the supply facility and the center-point. I had the fantastic help of an old, old friend. I plan on taking a few pictures to post tomorrow. One thing I debated was whether I would set up a detailed map of the node locations, but due to the concerns about privacy of the end-users and worries about node hijacking (something extremely remote, but possible), I am going to simply take pictures of the antenna installations. The center-point antenna was the craziest installation I have ever done - at one point, my buddy was riding the silo like the guy from Dr. Strangelove who rides the bomb to the end yelling yee-haa the whole way... And that was one of the more tame moments of us trying to get the antenna up while battling the 25-30 mi/hr winds (plus my insane fear of heights).
    I had been watching the weather all week to see whether it would be possible to do the work today or not. Yesterday would have been much more ideal, but at least it didn't rain today (other than 10 minutes around 7:30 after we had just gotten on top of the center-point). The center-point is at the top of a silo that supplies one of our facilities with raw materials for our product. I had the choice of five locations and debated the pros and cons of each by some objective and subjective guidelines:
1) Which center-point gives the greatest range of line-of-site to potential end-nodes.
2) Which center-point will have the most reliable source of power and be the easiest to maintain if something happens.
3) Which center-point will have the potential to be a bridge to other center-points - i.e. which location offers the best potential for continued growth. If the system were to grow to multiple center-points/nodes, which one would provide the most useful center-point?
4) Trying to minimize latency on a wireless network can be difficult due to reflection from natural and man-made objects. I tried to look at the surrounding buildings as reflectors - like multiple stones thrown into a pond and the ripple effects that collide. If my understanding of rf reflection is correct, then reflection can also be to your advantage. The problem is that predicting reflection versus absorption is practically impossible - at least I don't have the training to do so - nor do I have the understanding to do the calculations quickly. Plus, due to the varying heights of the buildings and different roof pitches, it would be even more difficult to figure out where the signal can and cannot go without simply relying on a line of site model.
    The silo we ended up mounting to has turned out to be better than I thought. We were able to reach some sites that I thought would be obstructed by other buildings. After finalizing the mount of the center-node antenna, we started work on the feed. The original plan was to use a tripod mount on a portion of the roof that had a 1-2 deg. pitch. Ironically, the wind that caused terror up until then, ended up becoming our saving grace - at least in the future we would have learned this to be a saving grace. Trying to mount a 10 ft. mast to an relatively small tripod base (without being able to screw it to the roof - holes in roofs eventually leak...) turned out to be all but impossible - the wind whipped around the base even with 25 lbs. weights on each of the feet. We ended up having to use a side mount method whereby mounts are attached to the side of the building. We were able to mount a 20 ft. mast using a 5 ft. standoff between the two mounts. The antenna mast ended up flexing quite a bit in the wind, but the flex proved to be a means by which neither the antenna nor mast were damaged by the wind. I will eventually replace the directional patch at the top of the mast with a mini grid antenna so that wind is less of a factor. The beam width and antenna sensitivity differences are negligible, so weather is really the issue.
    After testing the link between feed and center-node, we cleaned up and put power/surge protection in place (on the base stations and between the center-node antenna and the base station). So, the link is up and running... 8 Hrs of work and we have a functioning core. Tomorrow I'll do so more signal tests from different points and see if we need to make any further adjustments to the center-node. From here, we will start installing end-nodes and testing over-all network performance.

The Latest Challenge: Darien Wireless Co-Op

| | Comments (0)

    It started out as an idea that had been haunting me over the past few years, but now it just might become a reality. You see, we live out in the sticks. Out in the country. Out in the middle of nowhere. After working for Hillsdale College and having gotten used to the raw power of a T1 and a host of servers to play with, I had a somewhat difficult time adjusting myself back to country life (a little over three years ago, my wife and I moved back to my home town so that I could start working with our family businesses). After playing with three phone lines and multiple dial-up accounts, then testing the fledgling two-way satellite internet service, I came across (a now defunct company), Dakota DSL. They ended up changing their name, but its been so long and the service was so short lived that I can't even remember anymore. I polished up some old workstations I had accumulated over the years and others gotten off of eBay and put Windows NT Server on two machines and started my own little webhosting operation. It was costing me a fortune, but still better than anything I had seen since moving back to Wisconsin. At the time, Aaron and I did a little webhosting off of the servers for both of our domains. It didn't become anything more than two pokey websites because about three months into it, we got hacked... We were hacked pretty badly, too. So, I researched around and around and around and realized that upgrading to newer versions of Windows NT was going to be too costly, so I decided to learn what I needed to do to get our services running on some form of Linux or Unix. By that time, Aaron had split - found a better and more reliable host - and I was convinced I could do webhosting better and cheaper than anyone else. I took about three more months and learned the basics of FreeBSD and got apache, qmail, php4, mysql and a host of other services running on my first FreeBSD box. I also learned that I couldn't do webhosting better and cheaper than anyone else because 1) I had a real job and 2) the box that was hanging off the net was 15 minutes from work - so any time there were troubles, there were troubles. It suited my needs, but I needed stronger, faster and more of everything in order to make the venture work. Then Dakota went bankrupt and I lost my super fast connection. Then, we also got kicked out of the house we were living in (not really, but the owners wanted to move back in and we had to look for a new place to rent or buy). So, I shut my website and hosting service (of one) down and took a 4 month hiatus.
    Between then and now, I have been on Charter in one form or another and have amassed a server farm that makes my head swim (when I realize the money I have sunk into my addiction). I had, at one time, a neighborhood wireless network running - which is what got me started on this topic in the first place - whereby I supplied some of my neighbor/friends with access to my mega-pipe to the net and they helped defray the cost of my service. My wife and I ended up moving, yet again, to a place where I think we'll stay put for some time to come. We also moved our offices and are closer to where I live and are in a business park - whereas before, we were literally in the middle of a very large corn/soy bean field.
    If you are still reading by now, you are either entranced by my writing, you are on the loo with your wireless laptop and having nothing better to read or you are trying to sleep - BUT, I'm actually getting to a point. I'm starting up another wireless project. This time, however, my project has no grand goals other than covering my @ss on bandwidth expenses. I don't want to be the worst and if you graded what I want to do solely on price, I can't be the best - but I can give you the best experience for your dollar and help us help each other. If you are somewhere near this area (click on the link and you will see an amazing little satellite photo), then there is a good chance I can get you online. Sure, there is competition (GenevaOnline and ElkNet - and a few other dial-up entities), but I think we can beat them in every way - price, service and accessibility. But, we can only do it by pooling our resources. I found some great equipment by Proxim and some people who seem genuinely interested in the project. I hope to use this site to document my progress. I have a few goals in mind and would like to put up a chronology of what happens:
1) Get the center base station up and running this weekend.
2) Get final commitment from other users (hopefully 10 of us will sign up).
3) Based upon final commitment, I will put in my T1 orders.
4) Get a few subscribers up and running next week.
5) Keep those subscribers up and running...
6) Get the rest of the subscribers up and running.
7) Keep the rest of the subscribers up and running...
8) Monitor bandwidth to make sure we are utilizing it to the best of our abilities.
9) Put in redundant nodes in case the main node goes down.
10) ...I'm thinking residential on a different scale than approached by ISP's before. Fully private addressing scheme, SPAM filters on all email addy's and nodes supplied by private DSL lines all over the city and countryside. P2P sharing limited to 256kbps of overall bandwidth... period. A ResNet for Darien, built in much the same fashion that the Co-Op is designed to run - a few volunteers and a lot of users.

We'll see how it goes...

About this Archive

This page is an archive of entries from March 2004 listed from newest to oldest.

February 2004 is the previous archive.

April 2004 is the next archive.

Find recent content on the main index or look in the archives to find all content.

Contact

Steven N. Fettig
Delavan, WI - somewhere between Delavan & Darien: map link
Phone: +1 262 432 1704
Email: snfettig AT gmail.com
AIM/Yahoo/MSN/GoogleTalk-
Skype/twitter:
snfettig

Technorati

Technorati search

» Blogs that link here

Powered by Movable Type 4.21-en