Re: [WISPA] Best system for a new WISP

[Tom DeReggi]

Travis,

Am I missing something?

Yes you are.  The results you are explaining are appropriate for Layer2 
testing and UDP testing.
(2% packet loss = 2% reduction in speed)

Its different with TCP and way different with FTP.

Understanding its 1:30am, my mind is shot after a 20 hour work day, and my 
theory may be a little weak as explanation, however the gist of it is....

TCP is a transmission Control Protocol, meaning it controls the flow of data 
when and how fast to transmit.  Or in other words, detects when their is 
packet loss, and slows it self down when it occurs. If a PC sends data 
faster than the Link capacity, packet loss occurs. All TCP links have some 
level of packet loss. For example, common Bandwdith management programs 
purposely drop packets (thus packet loss) in order to slow down transmission 
of data to a specific speed. What keep a PC from sending 10 mbps of data 
across a 1 mbps link? The Answer is TCP. It slows down transmission to meet 
the speed of the link, determining that based on when packet loss occurs. We 
are talking very very low amounts of packetloss, for TCP to tune itself for 
error free transmission.  However, when there is a large amount of packet 
loss (such as 2 %), it slows transmission way down, as TCP tries to resend 
lost packets, and instead of it getting done at the radio, it has to go all 
the way back to the PC to determine when data was not delivered and when 
needed retransmission. This is because transmission is connection based with 
TCP, a connection between PC and end destination. So if a packet is lost on 
a hop, there may be many hops of packets to determine that re-transmission 
is needed, adding large amounts of latency, slowing transmission to a 
screaching halt.

Now of course Trango solves this problem with its ARQ feature. When you get 
2% packetloss, the link speed goes down 2% plus a small overhead amount, and 
the end applications, PCs, and other OSI layers dont even know the 
packetloss occured, as Trango transparently corrected it.

Many have argued a method of ARQ is part of the 802.11 protocol for reliable 
delivery, which is true, but the performance hit in terms of throughput and 
latency is huge. Not to mention some faster versions of 802.11 (a/g) may 
even get rid of some of those features in order to deliver the faster 
speeds. But I forget the theory on all that, so I won't go into it in this 
post.

The second issue is how FTP operates. Beyond TCP native transmission 
control, my understanding is that FTP's application layer, also has routines 
to help control reliable delivery of data transfer. (UNless I am mistaken, 
and its jsut TCP doing its stuff).  FTP tries to self correct transmission 
errors. If FTP sees any packet loss, it slows transmission, and if there is 
still packet loss, it slow transmission more, etc. Because packetloss on a 
wireless link often is not a factor of speed of transmission, (for example 
random interference which occurs a percentage of the time (time based) 
regardless of speed of data transfer), it never manages to correct errors in 
transmission (packet loss) by slowing down, so it keeps on slowing down more 
attempting to correct, until it is transfering the speed of dial UP.

Layer3 and UP protocols are smart. They don't jsut accept that 2% of packets 
get lost. They have to do something about it, to increase reliabilty. That 
can come at a HUGE performance penalty. The protocols accept that as the 
idea is that generally there should not be packetloss of significant amount, 
just mild loss from congestion. However, thats not the case in Wireless 
applications. 2% packet loss extending back to the end user PC for 
correction, can DESTROY performance. How much? Depends on what application 
and what the thresholds are in their code. How TCP works and its thresholds 
are published under an RFC somewhere.   There ar some charts I saw that 
charted how much performance is lost based on what percentage of packet loss 
occured. A small amount of packet loss has a small effect on packet loss, 
but a large amount has an exponential effect, and harms transfer at a much 
greater rate than the amount of inital packet loss.

So back to testing...
If using a TCP speed tester, it takes into account any packetloss in the 
link, and handles slowdown however TCP is designed to do it. So the speed 
tester will immulate what real world data transfer would be for a raw TCP 
application the end user would use.

Where the problem occurs in testing speed, is when the end user application 
(such as FTP) uses its own criteria on what methods it uses to correct poor 
data transmission. It does not follow jsut the default TCP protocol code. It 
injects decssions from its application level code. We have noticed 
specifically with FTP, the rate it slows down is tremendously more than just 
the amount of packet loss on the radio. Thats not a bad thing, people want 
their data delivered in its entirety error free, which is what FTP is 
designed to do.

I argue that FTP is one of the best tests for testing link quality, because 
if link quality is poor, you see it right away in performance.

However, it takes a lot of over head for FTP. Slow PCs may not be able to 
reach full link speed running a typical windows based FTP program.  Thats 
why programs like IPerf are good, they have low overhead, and still perform 
at pretty high speeds on slower PCs.

When critisizing StarOS's speed tester, I was not saying it was not good. I 
was more asking if its results were compared against FTP in high packet loss 
situations? If his test uses similar techiques as FTP not jsut TCP, it very 
well may gives results equivellent to real world FTP transfers.  But I don't 
know that.  Lab tests, and tests under significant packet loss could have 
much different results comparing Native TCP tests with FTP tests.

I also like Iperf because of its abilty to change packet size, and see how 
that effects throughput. Large packets can bring out more packet loss from 
falws in link. However, to small packet loss also can have negative effect. 
Sometimes both tets are needed to get a clear picture of what the end user 
is feeling. Its not easy being certain, gusessing what performance the 
consumer is feeling, when you are remote at your office desk.  What do you 
do when you thing performance should be good, but the custoemr says its not? 
Do you do a ttuck roll to prove it? Not if you have the right tools, to test 
all the variations.

Tom DeReggi
RapidDSL & Wireless, Inc
IntAirNet- Fixed Wireless Broadband


----- Original Message ----- 
From: "Travis Johnson" <[EMAIL PROTECTED]>
To: "WISPA General List" <wireless@wispa.org>
Sent: Wednesday, April 12, 2006 9:46 PM
Subject: Re: [WISPA] Best system for a new WISP


Tom,

I am confused about your testing. If you are testing a link, and it has 2% 
packet loss, then the link is going to run 2%-4% slower due to the loss, 
therefore the results will reflect that loss.

Ever run a speed test across a link with 50% loss? If it's set to a 2Mbps 
connection, you get about 1Mbps when testing. It's still a 1Mbps 
connection, even with packet loss. Even using Trango's Linktest, it shows 
the maximum speed of the link BASED ON THE LOSS across the link.

Am I missing something? I don't understand what you are trying to say.

Travis
Microserv

Tom DeReggi wrote:

Ok, assuming Real World Test win.....

How does your TCP test handle packet loss? Does it slow the test down to 
attempt to reduce packet loss until its gone?
Thats what real world applications do, like FTP, and the real performance 
subscribers see, regardless of the Link's abilty to pass test traffic 
faster.  I want to see the performance my customers experience.

If your link has 2% packetloss, what impact will that have on customer's 
performance with various applications? Will your TCP tests show that. 
I'm not passing judgement, I'll let you make that judgement you wrote it. 
But my TCP tests (Iperf) do not get me that information.  I've lost 
customers insisting that their link was operating perfectly based on TCP 
speed test, only to learn that the custoemr was right, and their 
performance was getting destroyed by packet loss. This is an important 
issue with Wireless, when packet loss is possible, due to interference 
and environmental condition changes.

WRAP board were always in the 23
to 25 mbps range yet a UDP test would pull almost 35 mbps,


Our testing never saw that.

Typical numbers were always in the 1,800 to 2,000
KBytes/sec as reported by the FTP client.


I don't contest that, based on a lab environemnt without packetloss.
Did you repeat those tests, introducing interference/packet loss into the 
link?
2% packet loss with FTP, can bring your performance of a 25 mbps link 
down to 100 kbps.
Does your test, replicate those results?

I agree that TCP is a preferred test for a clean lab environment test, to 
test maximum obtainable speed.
Butwho cares about that? What I want to know is what speed my link in the 
field is capable of doing, based on the conditions it is deployed in.

I'm not in the business of delivering commodity Up-To Burstable Services.

I am always amazed at how labels get applied.  To call something a
lower grade product


Understand, I was not saying your product is lower grade than other, buts 
saying that your product is not being as good as it can be, if it had 
more types of testing tools. Its what, a days work, to add Iperf to OS 
image?

>Results are what count, not

how pretty you look or how good you sound.


But how do you know what your results are? If tests don't test 
accurately?

It is strange
to have to lie to the customer to get a high grade product rating.
Maybe we don't need that, and for the most part my users don't want it
either.  They don't want packet loss either.  Most of them prefer to
have the whole file delivered intact.


This is where you are loosing me. I'm not aware of anyone that lies to 
give a higher grade offering.
My comments are based on results I see in the field with live 
deployments, that cost me clients and save me clients.
I don't sell product or profit from what product user's select.

I am not judging your test tool, I have never performed test measuring 
the accuracy of your testing tool. I am simply asking you the real hard 
question, for you to evaluate whether your test tool, method considers 
all the factors that need to be tested. You tell me, but prove it, with 
an explanation of how your tool handles it.

Lonnie, its no big deal to us, we got a solution. We got Iperf running at 
every hop cell router, and have XP versions of Iperf to Email to our 
subscribers when tests need to be performed.  Not all WISPs are in that 
position. Its to your advantage, to add the tools that WISP may want, 
sothey can make their technical decissions that meet their standard what 
ever tyhat may be, apposed to being locked into the vendor's opinion.

Lonnie, StarOS is a great product, I'm not trying to say otherwise, nor 
am I challenging the speed capabilties of the product. I'm jsut 
discussing test variables.

I admit, I tend to use Mikrotik more for my APs, because of the Virtual 
AP feature. Why? Because it saves me $200 a month per radio on roof lease 
fees, because I now can have one AP for all my wifi needs, instead of 
multiple APs on the roof for various needs, and I only need one channels 
for all my needs, instead of multiple channels for various needs. (Wep 
compatibilty mode, WPA high security mode, HotSpot Free public access, 
VLAN protected provisioning mode).  It will be great when you get Virtual 
AP added to the product. It gets hard for me to test performance between 
a StarOS client and a Mikrotik AP, without a standardized test tool 
embedded in the radio. I got Iperf on the cell servers. But I'd love to 
be able to test performance to the CPE, without calling the customer to 
assist, and see the results I'm getting on the spot. It puts me in a 
vulnerable possition SLA wise and response time wise.

You can take the advise or leave it. Just my 2 cents.

Tom DeReggi
RapidDSL & Wireless, Inc
IntAirNet- Fixed Wireless Broadband


----- Original Message ----- From: "Lonnie Nunweiler" 
<[EMAIL PROTECTED]>
To: "WISPA General List" <wireless@wispa.org>
Sent: Wednesday, April 12, 2006 7:33 PM
Subject: Re: [WISPA] Best system for a new WISP


This may be the case, but the test we perform seems to describe what
we see in real life use.  As long as you have consistency it does not
matter what you do.  The ability to compare apples to apples is what
is truly important, and since we began to use TCP many years ago, we
still continue to do so, since it gives us a relevance and comparison
to the systems in current use.

My TCP numbers are lower than you'll get with a UDP test, so I am
quite happy to compare my TCP to UDP because my TCP numbers are pretty
nearly as high as numbers I hear reported for other high end systems
that test with UDP.

For instance, our TCP numbers on a  WRAP board were always in the 23
to 25 mbps range yet a UDP test would pull almost 35 mbps, which is a
number I have never seen even in my dreams doing an FTP transfer (with
the WRAP boards).  Typical numbers were always in the 1,800 to 2,000
KBytes/sec as reported by the FTP client.

Our goal is to give you numbers you will see in real life.  After all,
your user is going to be ragging on you based on the FTP results they
see.

I am always amazed at how labels get applied.  To call something a
lower grade product because of a test method sure indicates a
conclusion that needs to be re-examined.  Results are what count, not
how pretty you look or how good you sound.

We have come pretty close to the goal of real world numbers, so I am
not fazed at all by your lower grade product ranking.  It is strange
to have to lie to the customer to get a high grade product rating.
Maybe we don't need that, and for the most part my users don't want it
either.

They don't want packet loss either.  Most of them prefer to
have the whole file delivered intact.


Yes, but that really isn't a choice made or controled by the ISP, we 
deploy in a dynamic environment that changes. I remember when I was green 
in this industry, and rode my high horse, and stated, "Links should be 
engineered for no packet loss from the beginning". In that is exactly 
what we did!  But environments change. When a competitor points a Radio 
at your cell site from 300 yards away, packet loss occurs, nothing can be 
done about it on the spot. re-engineering must take place to illiminate 
packetloss.  How much time will a WISP have to correct packet loss, 
before they lose their subscriber? I can tell you that Trango ARQ, bought 
me months of time to get around to making a re-engineering repair.  The 
first step, is to realize the performance of a link, to know how severe 
it is, and what steps need to be made to correct it. Every tool in the 
toolbox, helps deal with running a better operation as a WISP.


Regards,
Lonnie

On 4/12/06, Tom DeReggi <[EMAIL PROTECTED]> wrote:

Lonnie,

Unfortuneately, not having UDP tests, does not allow accurate results. 
The
reason is that UDP will show the point at which packet loss will occur, 
and
at what percentage. Without that similar data, a TCP test is pointless. 
I
see some people do TCP speed tests (a method other than FTP), and it 
goes
full capacity minus the percent packet loss of a percent or so. But then
when a FTP gets done performance drops to a few hundred kb. The reason 
is
FTP slows itself down to attempt to reduce packetloss. IN many wireless
systems, the packetloss stays consistent and can not be removed by 
reducing
speed, therefore the speed just keeps going slower and slower and slower
until it crawls. A TCP test also does not show consistency of a link, or
sparatic slow down, as they all get averaged out over the time period of 
the
test.  If there are slowdown or hesitance on a wireless link  using a 
UDP
test, the packetloss is instantly seen.  Doing a TCP test may show peek
speed or average speed, but it does not show the ability to deliver
consistent speed, what most companies need that are buying wireless to
replace T1 lines.

Relying on TCP test alone, limits your product to a lower grade product,
less than it can be.  An adequate test, does not need to be a UDP test, 
it
can also be a layer2 test. The most valuable tool of Trango for example 
is
its Layer2 Linktest, that shows throughput, and most importantly 
packetloss
while performing that test.  It gives the abilty to run a test that 
takes
priority over any other traffic on the link, to get the true full
performance of that link at that moment in time.  It allows an 
integrator to
instantly be able to determine the health of their links with total
accuracy, quickly, without first disconnecting clients, that can be
complicated, when multiple Linux re-configures might be needed to stop 
all
other traffic.

For radios that don't have their own MAC, Iperf is one way to get most 
of
the data collected. Measuring packet loss is more important than 
measuring
top speed in my mind.

Tom DeReggi
RapidDSL & Wireless, Inc
IntAirNet- Fixed Wireless Broadband


----- Original Message -----
From: "Lonnie Nunweiler" <[EMAIL PROTECTED]>
To: "WISPA General List" <wireless@wispa.org>
Sent: Tuesday, April 11, 2006 9:54 PM
Subject: Re: [WISPA] Best system for a new WISP


It is TCP.  We do not use UDP since it gives a reading that will never
be seen by a customer doing an FTP download.  We are looking at
building in iperf so we should be able to do tcp or udp tests in
future.

I have a network from Valemount, BC to McBride, BC that has about 100
km of repeater distances.  The shot is split in half with mountain
shots at each (43 km each) and about 5 km from each mountain top to
the POP in each town.  We can pull over 20 mbps from POP to POP.  It
is 8 hops and goes through 10 radios.  I have pasted a speed test from
the POP in Valemount to the POP in McBride.  Both are Linux systems
with 1 GHz or better processors that we use for firewall and bandwidth
control.  Also I have the traceroute to show the hops.

lon-home:~/staros # starutil-1.14 10.10.29.1 password -rx
rx rate: 2286 KB/sec  (Press Ctrl-C to exit)
lon-home:~/staros #

lon-home:~/staros # traceroute 10.10.29.1
traceroute to 10.10.29.1 (10.10.29.1), 30 hops max, 40 byte packets
 1  192.168.250.10  0.430 ms   0.401 ms   0.496 ms
 2  10.10.48.254  1.655 ms   1.447 ms   1.185 ms
 3  10.10.227.254  2.686 ms   1.965 ms   5.428 ms
 4  10.10.12.4  5.469 ms   3.250 ms   4.501 ms
 5  10.10.47.253  4.946 ms   4.415 ms   3.581 ms
 6  10.10.51.254  6.077 ms   6.472 ms   8.063 ms
 7  10.14.99.254  12.615 ms *   5.777 ms
 8  10.10.29.1  6.569 ms   7.295 ms   7.686 ms
lon-home:~/staros #

Lonnie

On 4/11/06, Travis Johnson <[EMAIL PROTECTED]> wrote:
>  Lonnie,
>
>  Is that TCP or UDP?
>
>  Travis
>  Microserv
>
>
>  Lonnie Nunweiler wrote:
>  Using the 533 MHz IXP-420 we can get an Atheros to just over 35 mbps
> of non compressible data and almost 90 mbps of compressible data.
>
> Lonnie
>
> On 4/11/06, Travis Johnson <[EMAIL PROTECTED]> wrote:
>
>
>  Dan,
>
>  We had this discussion a few weeks ago, although it may have been on
> another wireless list.
>
>  What processor and setup are you using to get 30Mbps? The fastest
I > have
> seen with routerboard 532's in a p2p config is 20Mbps of TCP traffic
> passing
> thru the RB's. Do you have outdoor enclosures?
>
>  Travis
>  Microserv
>
>
>  [EMAIL PROTECTED] wrote:
>
>
>
> I believe that the atheros chipset is capped at 35Mbps, although
users > of
> MT
> have claimed higher using very fast cpu's.
>
>
>
> I have several atheros/MT/nstream links (PTP and PTMP) that push >
30Mbps….
> Pretty impressive throughput, plus adjustable channels, plus QoS
for > VoIP
> and all the other features available make a nice system
>
>
>
>
>
>
> Dan Metcalf
>  Wireless Broadband Systems
>  www.wbisp.com
>  781-566-2053 ext 6201
>
> 1-888-wbsystem (888) 927-9783
>  [EMAIL PROTECTED]
>  support: [EMAIL PROTECTED]
>
>
>
>
>  ________________________________
>
>
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Travis
> Johnson
>  Sent: Tuesday, April 11, 2006 9:28 AM
>  To: WISPA General List
>  Subject: Re: [WISPA] Best system for a new WISP
>
>
>
> Hi,
>
>  Does anyone know actual TCP throughput with StarOS on their 533mhz 
> boards
> in just a point to point config, using 20mhz of spectrum?
>
>  Travis
>  Microserv
>
>  Paul Hendry wrote: All the details are on the Valemount web site
>
>  http://www.staros.com/starvx/
>
>  Cheers,
>
>  P.
>
>  -----Original Message-----
>  From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
>  Behalf Of Richard Goodin
>  Sent: 11 April 2006 09:15
>  To: wireless@wispa.org
>  Subject: RE: [WISPA] Best system for a new WISP
>
>  So... Who makes them?, how much?
>
>
>
>
>  Hi Richard,
>
>  This cloaking mechanism is the 5MHz and 10MHz channel sizes that
>  George was referring to on the Star WAR boards. Works really well and
> even
>  seems to improve signal quality.
>
>  Cheers,
>
>  P.
>
>  -----Original Message-----
>  From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
>  Behalf Of Richard Goodin
>  Sent: 11 April 2006 08:09
>  To: wireless@wispa.org
>  Subject: Re: [WISPA] Best system for a new WISP
>
>
>
>
>  Guys;
>  These all sound great. I was reading just a couple months back
about a
>  WISP
>
>  operator that had a severe problem. Just a few yards away, maybe 300
> feet,
>  another guy put up his tower. I think they were both on 2.4 GHZ, and
>  someone suggested a different AP that would not even be detected by
>  conventional systems. Something about nonstandard bandwidth, channel
>  spacing or coding. I really feel that stealth is best here. These
other
>  guys have been in business for a while and could cause trouble
that I > do
>  not
>
>  need.
>
>  Lee
>
>
>  Trango does make a good product. I still have 2 Sunstream AP's in
use.
>
>  They
>
>
>
>  are like Timex watches.
>
>  I'm using Star War boards. A little bit more than the trango s. The 2
>
>  card
>
>
>  boards in a 5 gig rootenna let me use the 2nd card for an omni.
>  Speeds are about 20+ megs or so and I cloak down to 5MHz and 10MHz
>
>  channel
>
>
>  sizes.
>
>  One of the things I've been doing is slapping up repeaters all
over the
>  place. Cheap as hell, about 400.00 or so.
>
>  Lately I've ran lmr400 into some of my customers attics and
installed > an
>  omni for their home wifi. We tend to service our customers right
to the
>
>  pc
>
>
>  and it's a lot better router than a linksys. And I have happier >
customers
>  and I'm happier.
>
>  The 2 port and the 4 port both have dual ethernet as well.
>
>  Pretty versatile product. Lonnie has come along way with the new war
>  platform.
>
>
>  George
>
>
>
>
>
>  Travis Johnson wrote:
>
>
>  That's on quantity 30.... $149 each. 5.8ghz, dual polarity, up to 3
>
>  miles
>
>
>
>  (add $40 for a dish and it goes up to 13 miles) and delivers up to
>
>  10Mbps.
>
>
>
>
>  Hard to beat! And with SmartPolling on the AP, you can get
hundreds of
>  customers per sector.
>
>  Travis
>  Microserv
>
>  Rick Smith wrote:
>
>
>
>  that's only quantity (large!) pricing isn't it ?
>
>  Brian Rohrbacher wrote:
>
>
>
>  If it's pretty absent of trees you might look at 5.8. Trango has that
>  cpe for $150. Not going to find any propriety gear cheaper.
>
>  Richard Goodin wrote:
>
>
>
>  I have been planning my WISP for about a year, and have yet to begin
>  delivery of bandwidth to customers. My choice for service delivery
>
>  was
>
>
>
>
>
>
>  802.11b, but with increased competition from other services nearby
>  (about 5 miles away) I am wondering how to avoid problems. I have a
>  50' tower, and it is ROHN 45g. My choice for antennas would be 4 90
>  degree horizontal antennas. I have looked at bandwidth and shopped
>
>  it
>
>
>
>
>
>
>  to death. My best price is $400 from Lime Light. And I've built a
>  couple of servers, acquired some switches and a router. The Router
>
>  is
>
>
>
>
>
>
>  a Cisco 1750.
>
>  My questions:
>
>  What CPE's and AP's would work best in this environment? I want to
>  keep interferance to a minimum, as well as control costs. My
>  environment includes lots of desert, and single story buildings.
>
>  Lee
>
>
>
>  --
>  WISPA Wireless List: wireless@wispa.org
>
>  Subscribe/Unsubscribe:
>  http://lists.wispa.org/mailman/listinfo/wireless
>
>  Archives: http://lists.wispa.org/pipermail/wireless/
>
>
>  --
>  WISPA Wireless List: wireless@wispa.org
>
>  Subscribe/Unsubscribe:
>  http://lists.wispa.org/mailman/listinfo/wireless
>
>  Archives: http://lists.wispa.org/pipermail/wireless/
>
>  --
>  No virus found in this incoming message.
>  Checked by AVG Free Edition.
>  Version: 7.1.385 / Virus Database: 268.4.1/307 - Release Date: >
10/04/2006
>
>
>  --
>  No virus found in this outgoing message.
>  Checked by AVG Free Edition.
>  Version: 7.1.385 / Virus Database: 268.4.1/307 - Release Date: >
10/04/2006
>
>
>  --
>  WISPA Wireless List: wireless@wispa.org
>
>  Subscribe/Unsubscribe:
>  http://lists.wispa.org/mailman/listinfo/wireless
>
>  Archives: http://lists.wispa.org/pipermail/wireless/
>
>
>
>
>
>
>
> --
>  No virus found in this incoming message.
>  Checked by AVG Free Edition.
>  Version: 7.1.385 / Virus Database: 268.4.1/307 - Release Date: >
04/10/2006
>
>
>
>
>
> --
>  No virus found in this outgoing message.
>  Checked by AVG Free Edition.
>  Version: 7.1.385 / Virus Database: 268.4.1/307 - Release Date: >
04/10/2006
>
> --
> WISPA Wireless List: wireless@wispa.org
>
> Subscribe/Unsubscribe:
> http://lists.wispa.org/mailman/listinfo/wireless
>
> Archives: http://lists.wispa.org/pipermail/wireless/
>
>
>
>
>
> --
> Lonnie Nunweiler
> Valemount Networks Corporation
> http://www.star-os.com/
>
>
> --
> WISPA Wireless List: wireless@wispa.org
>
> Subscribe/Unsubscribe:
> http://lists.wispa.org/mailman/listinfo/wireless
>
> Archives: http://lists.wispa.org/pipermail/wireless/
>
>
>


--
Lonnie Nunweiler
Valemount Networks Corporation
http://www.star-os.com/
--
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/

--
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/



--
Lonnie Nunweiler
Valemount Networks Corporation
http://www.star-os.com/

--
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/ 

--
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/