Travis,

Its real easy to demonstrate my point with Atlas PtP gear.
You can hard set at various modulations, and start lowering power, until linktest shows the percentage of packetloss you want to test. Linktest is great to measure loss to tell when you got it at the right level for testing. (not nearly as easy with 802.11 gear to test, as hard to measure what the packet loss actually is at a given moment for accurate comparisons).
Of course disable ARQ for testing.
Then do the FTP.
Just add 3-5% packet loss, and watch how slow FTP gets. The more hops you have between the Host and CLient FTP machines, the worse the performance gets affected by the packet loss.

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/

Reply via email to