I am missing something here. You say a TCP test runs full speed even in the face of packet loss. My experience does not bear this out. We see good results in our tests because we have links with little or no packet loss. You can be assured that throughput results drop in the face of packet loss.
On the other hand you can get a much higher number with a UDP test. You understand that UDP is connectionless and does not rely on any sort of feedback (the periodic ACK) and just blindly pumps out packets, with no knowledge that they were ever received. iperf does talk back and forth to get an idea of how many packets make it through, but I could easily do a UDP test that would be at the full speed of the device I am sending it from, yet the other end could have a 100% blockage. A TCP test would immediately show that as 0 throughput. Anyway, this is digressing and getting personal, with shots at things that have zero to do with throughput. I now go back to lurk mode. Lonnie On 4/12/06, Tom DeReggi <[EMAIL PROTECTED]> 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/ > -- 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/
