Re: [WISPA] Best system for a new WISP

[Tom DeReggi]

Travis,

I agree my explanation is not complete regarding detail working of the 
protocols, and see your logic in your response, that what would FTP do if 
TCP already took care of it already.  However, it doesn't work that way 
exactly. Does TCP fully take care of it? There are limits on how TCP works, 
and to truly understand them, I suggest you read the RFC, as its just been 
to long, since I read them, to explain them well.  I don't need to remember 
the details anymore, just that the phenominon exists to watch out for. Part 
of it has to do with the reaction time TCP has to scale up and down speed. 
And when 802.11, waits for retransmission, how does TCP react to that? They 
have different timing rules in their decissions. I don't know the answers, 
why.

Personally, I feel its the developer's job to figure that stuff out. My job 
is to sell radios. My job is to disclose real world findings, so it keeps 
the developers on their toes to consider everything they need to consider in 
doing their job.

All I can tell is, create 3-5% packet loss consistently on a link, and 
perform an FTP, and watch the degregation escalate.  And then watch and see 
if Iperf's TCP performance matches. Or for that matter perform a web based 
speed test, which can not be recognized as accurate, but regardless, the 
customer will through the Dial-UP speed results in your face, creating 
unnecessary support headache, so its relevant how the link responds to them.

I have two tasks slated on my R&D table.

1) Compare Alvarion and Mikrotik throughput in noisy environments.
2) Compare FTP and IPERF TCP tests over 802.11 gear, at various packet 
losses, and chart. (most of my real world is with TDD).

But I probably won't get to it for a while, things are backed up and busy on 
the install front.

I'd love someone to join this thread, that has detailed knowledge of the 
protocols, that could give a detailed explanation for us.
Or step up to the plate to run the tests sooner, and report the results.

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


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


Tom,

Again, I am confused. You state that TCP will correct for packet loss it 
detects... so in that case, FTP would never see the packet loss because 
TCP is already "correcting" for the loss.

My point was, if you have a link with 2% loss, it will show up doing a TCP 
test by being slower than expected.

Travis
Microserv

Tom DeReggi wrote:

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/ 

--
WISPA Wireless List: wireless@wispa.org

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

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