[WISPA] ePMP PTP Results
I spent some time tonight working with a couple ePMP radios on a test link and thought I'd share some results since I didn't get much feedback when I asked about this use case a couple weeks ago. Setup The link is a 7.5 mile link in a fairly noisy area, it has 2ft ubiquiti rocket dishes with RF Armor shield kits and formerly had normal Rocket M5 radios. Mikrotik CCR on one end and RB450 on other end. Evaluated latency and throughput between the two routers using the RouterOS bandwidth test. Used 20mhz channel throughout test. On a noisy frequency where the link had been running, about -75 noise floor, the Ubnt link would pass around 40 mbps aggregate with low latency 10ms. The ePMP would pass about 70mbps with stable 18ms latency, but performance was inconsistent when changing direction (tx/rx/both) - almost like the noise was little higher in one direction and affecting link stability when I tried to run traffic in that direction. It seemed a little less stable overall on that freq than the Ubnt radios. Throughout the testing at this freq MCS varied 9-13. On a cleaner frequency (DFS band) I was able to achieve solid MCS15. The ePMP was able to deliver 100mbps aggregate throughput consistently, which I found very impressive. The most I usually see from normal Rockets in this type of test is usually around 70mbps. The ePMP latency performance was a little unusual however. I noticed that when I saturated the link, latency jumped up to 200-400ms. If I restricted bandwidth to 90Mbps, I got nice consistent 18ms pings. When I run this type of test on ubnt I do not see a latency spike like this. Mikrotik radios running NV2 do increase at saturation, but only to around 100ms typically. So I would say ePMP performance is worse in this regard. I also noticed some inconsistent performance with regard to the ping times expected for the fixed/flexible scheduling in the ePMP. When I was first testing, I ran flexible mode and saw pings generally 6-10ms. In fixed mode, I saw 17-18 ms which I think is what's expected. That was several days ago... tonight I was seeing the 17-18ms even though I'm set to flexible - almost like it's stuck. I am able to push nearly full speed in both directions so it is definatley not in fixed mode. Hope this feedback is valuable for you all. I think these radios could be a very good option for low cost ptp radio, it would be nice if they could get the latency spike reduced. Chris Fabien LakeNet LLC ___ Wireless mailing list Wireless@wispa.org http://lists.wispa.org/mailman/listinfo/wireless
Re: [WISPA] ePMP PTP Results
Excellent post Chris, thanks for the info. Is your final solution to just set a bandwidth limit at MT so as not to have the latency spike? On Mon, Mar 10, 2014 at 3:26 AM, Chris Fabien ch...@lakenetmi.com wrote: I spent some time tonight working with a couple ePMP radios on a test link and thought I'd share some results since I didn't get much feedback when I asked about this use case a couple weeks ago. Setup The link is a 7.5 mile link in a fairly noisy area, it has 2ft ubiquiti rocket dishes with RF Armor shield kits and formerly had normal Rocket M5 radios. Mikrotik CCR on one end and RB450 on other end. Evaluated latency and throughput between the two routers using the RouterOS bandwidth test. Used 20mhz channel throughout test. On a noisy frequency where the link had been running, about -75 noise floor, the Ubnt link would pass around 40 mbps aggregate with low latency 10ms. The ePMP would pass about 70mbps with stable 18ms latency, but performance was inconsistent when changing direction (tx/rx/both) - almost like the noise was little higher in one direction and affecting link stability when I tried to run traffic in that direction. It seemed a little less stable overall on that freq than the Ubnt radios. Throughout the testing at this freq MCS varied 9-13. On a cleaner frequency (DFS band) I was able to achieve solid MCS15. The ePMP was able to deliver 100mbps aggregate throughput consistently, which I found very impressive. The most I usually see from normal Rockets in this type of test is usually around 70mbps. The ePMP latency performance was a little unusual however. I noticed that when I saturated the link, latency jumped up to 200-400ms. If I restricted bandwidth to 90Mbps, I got nice consistent 18ms pings. When I run this type of test on ubnt I do not see a latency spike like this. Mikrotik radios running NV2 do increase at saturation, but only to around 100ms typically. So I would say ePMP performance is worse in this regard. I also noticed some inconsistent performance with regard to the ping times expected for the fixed/flexible scheduling in the ePMP. When I was first testing, I ran flexible mode and saw pings generally 6-10ms. In fixed mode, I saw 17-18 ms which I think is what's expected. That was several days ago... tonight I was seeing the 17-18ms even though I'm set to flexible - almost like it's stuck. I am able to push nearly full speed in both directions so it is definatley not in fixed mode. Hope this feedback is valuable for you all. I think these radios could be a very good option for low cost ptp radio, it would be nice if they could get the latency spike reduced. Chris Fabien LakeNet LLC ___ Wireless mailing list Wireless@wispa.org http://lists.wispa.org/mailman/listinfo/wireless -- -- SCS Clay Stewart CEO, Tye River Farms, Inc., DBA Stewart Computer Services 434.263.6363 O 434.942.6510 C cstew...@stewartcomputerservices.com “We Keep You Up and Running” Wireless Broadband Programming Network Services ___ Wireless mailing list Wireless@wispa.org http://lists.wispa.org/mailman/listinfo/wireless
Re: [WISPA] ePMP PTP Results
Very interesting, Chris, thanks If the latency is going up to 200-400 ms. and there are no other buffered network elements in the path, then it would seem to me that the ePMP has a very serious case of bufferbloat. This is sometimes done because it makes the radio seem to perform better on artificial speed tests (as it did), to the severe detriment of real-world performance. Nowadays, it's inexcusable. Are there any settings to control buffer sizes? Can someone find out from Cambium how much buffer is in there? On 3/10/2014 3:26 AM, Chris Fabien wrote: I spent some time tonight working with a couple ePMP radios on a test link and thought I'd share some results since I didn't get much feedback when I asked about this use case a couple weeks ago. Setup The link is a 7.5 mile link in a fairly noisy area, it has 2ft ubiquiti rocket dishes with RF Armor shield kits and formerly had normal Rocket M5 radios. Mikrotik CCR on one end and RB450 on other end. Evaluated latency and throughput between the two routers using the RouterOS bandwidth test. Used 20mhz channel throughout test. On a noisy frequency where the link had been running, about -75 noise floor, the Ubnt link would pass around 40 mbps aggregate with low latency 10ms. The ePMP would pass about 70mbps with stable 18ms latency, but performance was inconsistent when changing direction (tx/rx/both) - almost like the noise was little higher in one direction and affecting link stability when I tried to run traffic in that direction. It seemed a little less stable overall on that freq than the Ubnt radios. Throughout the testing at this freq MCS varied 9-13. On a cleaner frequency (DFS band) I was able to achieve solid MCS15. The ePMP was able to deliver 100mbps aggregate throughput consistently, which I found very impressive. The most I usually see from normal Rockets in this type of test is usually around 70mbps. The ePMP latency performance was a little unusual however. I noticed that when I saturated the link, latency jumped up to 200-400ms. If I restricted bandwidth to 90Mbps, I got nice consistent 18ms pings. When I run this type of test on ubnt I do not see a latency spike like this. Mikrotik radios running NV2 do increase at saturation, but only to around 100ms typically. So I would say ePMP performance is worse in this regard. I also noticed some inconsistent performance with regard to the ping times expected for the fixed/flexible scheduling in the ePMP. When I was first testing, I ran flexible mode and saw pings generally 6-10ms. In fixed mode, I saw 17-18 ms which I think is what's expected. That was several days ago... tonight I was seeing the 17-18ms even though I'm set to flexible - almost like it's stuck. I am able to push nearly full speed in both directions so it is definatley not in fixed mode. Hope this feedback is valuable for you all. I think these radios could be a very good option for low cost ptp radio, it would be nice if they could get the latency spike reduced. Chris Fabien LakeNet LLC ___ Wireless mailing list Wireless@wispa.org http://lists.wispa.org/mailman/listinfo/wireless -- Fred R. Goldstein k1io fred at interisle.net Interisle Consulting Group +1 617 795 2701 ___ Wireless mailing list Wireless@wispa.org http://lists.wispa.org/mailman/listinfo/wireless
Re: [WISPA] ePMP PTP Results
The test setup they had at AF did not give me much hope that they are doing real world testing they had the RF outputs from the SM's hard wired to the AP — Sent from Mailbox for iPhone On Mon, Mar 10, 2014 at 8:57 AM, Fred Goldstein fgoldst...@ionary.com wrote: Very interesting, Chris, thanks If the latency is going up to 200-400 ms. and there are no other buffered network elements in the path, then it would seem to me that the ePMP has a very serious case of bufferbloat. This is sometimes done because it makes the radio seem to perform better on artificial speed tests (as it did), to the severe detriment of real-world performance. Nowadays, it's inexcusable. Are there any settings to control buffer sizes? Can someone find out from Cambium how much buffer is in there? On 3/10/2014 3:26 AM, Chris Fabien wrote: I spent some time tonight working with a couple ePMP radios on a test link and thought I'd share some results since I didn't get much feedback when I asked about this use case a couple weeks ago. Setup The link is a 7.5 mile link in a fairly noisy area, it has 2ft ubiquiti rocket dishes with RF Armor shield kits and formerly had normal Rocket M5 radios. Mikrotik CCR on one end and RB450 on other end. Evaluated latency and throughput between the two routers using the RouterOS bandwidth test. Used 20mhz channel throughout test. On a noisy frequency where the link had been running, about -75 noise floor, the Ubnt link would pass around 40 mbps aggregate with low latency 10ms. The ePMP would pass about 70mbps with stable 18ms latency, but performance was inconsistent when changing direction (tx/rx/both) - almost like the noise was little higher in one direction and affecting link stability when I tried to run traffic in that direction. It seemed a little less stable overall on that freq than the Ubnt radios. Throughout the testing at this freq MCS varied 9-13. On a cleaner frequency (DFS band) I was able to achieve solid MCS15. The ePMP was able to deliver 100mbps aggregate throughput consistently, which I found very impressive. The most I usually see from normal Rockets in this type of test is usually around 70mbps. The ePMP latency performance was a little unusual however. I noticed that when I saturated the link, latency jumped up to 200-400ms. If I restricted bandwidth to 90Mbps, I got nice consistent 18ms pings. When I run this type of test on ubnt I do not see a latency spike like this. Mikrotik radios running NV2 do increase at saturation, but only to around 100ms typically. So I would say ePMP performance is worse in this regard. I also noticed some inconsistent performance with regard to the ping times expected for the fixed/flexible scheduling in the ePMP. When I was first testing, I ran flexible mode and saw pings generally 6-10ms. In fixed mode, I saw 17-18 ms which I think is what's expected. That was several days ago... tonight I was seeing the 17-18ms even though I'm set to flexible - almost like it's stuck. I am able to push nearly full speed in both directions so it is definatley not in fixed mode. Hope this feedback is valuable for you all. I think these radios could be a very good option for low cost ptp radio, it would be nice if they could get the latency spike reduced. Chris Fabien LakeNet LLC ___ Wireless mailing list Wireless@wispa.org http://lists.wispa.org/mailman/listinfo/wireless -- Fred R. Goldstein k1io fred at interisle.net Interisle Consulting Group +1 617 795 2701___ Wireless mailing list Wireless@wispa.org http://lists.wispa.org/mailman/listinfo/wireless
Re: [WISPA] ePMP PTP Results
Some clarification: These were $99 connectorized radios which I chose because I am interested in a cheap upgrade from rockets or a more stable alternative to mikrotik. On a 40mhz channel I'm sure you'd see a benefit from the gigabit eth ports on the $500 radios. When I say limiting it to 90Mbps eliminated the latency spike, that is true for aggregate as well. So If I limited it to 50Mbps TX and 40Mbps RX, it would not spike, if I limited TX to 50Mbps and left RX open, it would run up to ~55-60Mbps RX and then I saw the latency spike. I did this to eliminate 100mbps eth port as a bottleneck in testing. I am not real familiar with the Buffer Bloat issue Fred mentioned, but I can confirm I was seeing these results for 10 minutes constant using the Mikrotik bandwidth test, TCP, 20 connections, whatever packet size is the default (I think large). I was testing using a CCR at one end and a RB450 at the tower end. The 450 CPU may have been a bottleneck but througput was still much higher than the Rockets. I did ping the RB450 from a different interface and the ping times were normal so the latency spike was not due to CPU load on the RB450. Chris On Mon, Mar 10, 2014 at 9:01 AM, timothy steele timothy.pct...@gmail.comwrote: The test setup they had at AF did not give me much hope that they are doing real world testing they had the RF outputs from the SM's hard wired to the AP -- Sent from Mailbox https://www.dropbox.com/mailbox for iPhone On Mon, Mar 10, 2014 at 8:57 AM, Fred Goldstein fgoldst...@ionary.comwrote: Very interesting, Chris, thanks If the latency is going up to 200-400 ms. and there are no other buffered network elements in the path, then it would seem to me that the ePMP has a very serious case of bufferbloat. This is sometimes done because it makes the radio seem to perform better on artificial speed tests (as it did), to the severe detriment of real-world performance. Nowadays, it's inexcusable. Are there any settings to control buffer sizes? Can someone find out from Cambium how much buffer is in there? On 3/10/2014 3:26 AM, Chris Fabien wrote: I spent some time tonight working with a couple ePMP radios on a test link and thought I'd share some results since I didn't get much feedback when I asked about this use case a couple weeks ago. Setup The link is a 7.5 mile link in a fairly noisy area, it has 2ft ubiquiti rocket dishes with RF Armor shield kits and formerly had normal Rocket M5 radios. Mikrotik CCR on one end and RB450 on other end. Evaluated latency and throughput between the two routers using the RouterOS bandwidth test. Used 20mhz channel throughout test. On a noisy frequency where the link had been running, about -75 noise floor, the Ubnt link would pass around 40 mbps aggregate with low latency 10ms. The ePMP would pass about 70mbps with stable 18ms latency, but performance was inconsistent when changing direction (tx/rx/both) - almost like the noise was little higher in one direction and affecting link stability when I tried to run traffic in that direction. It seemed a little less stable overall on that freq than the Ubnt radios. Throughout the testing at this freq MCS varied 9-13. On a cleaner frequency (DFS band) I was able to achieve solid MCS15. The ePMP was able to deliver 100mbps aggregate throughput consistently, which I found very impressive. The most I usually see from normal Rockets in this type of test is usually around 70mbps. The ePMP latency performance was a little unusual however. I noticed that when I saturated the link, latency jumped up to 200-400ms. If I restricted bandwidth to 90Mbps, I got nice consistent 18ms pings. When I run this type of test on ubnt I do not see a latency spike like this. Mikrotik radios running NV2 do increase at saturation, but only to around 100ms typically. So I would say ePMP performance is worse in this regard. I also noticed some inconsistent performance with regard to the ping times expected for the fixed/flexible scheduling in the ePMP. When I was first testing, I ran flexible mode and saw pings generally 6-10ms. In fixed mode, I saw 17-18 ms which I think is what's expected. That was several days ago... tonight I was seeing the 17-18ms even though I'm set to flexible - almost like it's stuck. I am able to push nearly full speed in both directions so it is definatley not in fixed mode. Hope this feedback is valuable for you all. I think these radios could be a very good option for low cost ptp radio, it would be nice if they could get the latency spike reduced. Chris Fabien LakeNet LLC ___ Wireless mailing listWireless@wispa.orghttp://lists.wispa.org/mailman/listinfo/wireless -- Fred R. Goldstein k1io fred at interisle.net Interisle Consulting Group +1 617 795 2701 ___ Wireless mailing list Wireless@wispa.org
Re: [WISPA] ePMP PTP Results
On 3/10/2014 10:21 AM, Chris Fabien wrote: Some clarification: These were $99 connectorized radios which I chose because I am interested in a cheap upgrade from rockets or a more stable alternative to mikrotik. On a 40mhz channel I'm sure you'd see a benefit from the gigabit eth ports on the $500 radios. When I say limiting it to 90Mbps eliminated the latency spike, that is true for aggregate as well. So If I limited it to 50Mbps TX and 40Mbps RX, it would not spike, if I limited TX to 50Mbps and left RX open, it would run up to ~55-60Mbps RX and then I saw the latency spike. I did this to eliminate 100mbps eth port as a bottleneck in testing. Were you testing it on a radio with a 100 Mbps Ethernet port? That could certainly cause issues if you're pushing it hard; it can have a two-way aggregate, of course, well beyond 100 Mbps, but not knowing the setup, it's possible that the buffer delay was not in the radio but in the device feeding the radio. So I don't want to blame Cambium if it might have been a testing artifact. I am not real familiar with the Buffer Bloat issue Fred mentioned, but I can confirm I was seeing these results for 10 minutes constant using the Mikrotik bandwidth test, TCP, 20 connections, whatever packet size is the default (I think large). Bufferbloat is one of the biggest problems in real-world IP networks. It is when a router has too large a buffer. So packets arrive and are queued for long periods of time, creating large amounts of latency and jitter. Memory is cheap and some designers might not realize that buffer queues need to be limited in size. My quick'n'dirty rule is that no device buffer should be more than ten packets deep, though the math whizzes can be more accurate. But if there's a really large buffer, a single TCP flow may adapt to it and make a performance test look good. It's like 0-60 time on a car -- if that's your only metric, then terrible handling won't show up. It's almost like melamine in baby formula. Speed on networks is not all that matters, but it's an easy metric to talk about, so breaking things to improve a speed test is a temptation. BTW the whole bufferbloat thing blew up several years ago when a packet was clocked taking seven seconds (!) to get through an ATT Mobility 3G connection. Such old packets are worse than useless. I was testing using a CCR at one end and a RB450 at the tower end. The 450 CPU may have been a bottleneck but througput was still much higher than the Rockets. I did ping the RB450 from a different interface and the ping times were normal so the latency spike was not due to CPU load on the RB450. Chris On Mon, Mar 10, 2014 at 9:01 AM, timothy steele timothy.pct...@gmail.com mailto:timothy.pct...@gmail.com wrote: The test setup they had at AF did not give me much hope that they are doing real world testing they had the RF outputs from the SM's hard wired to the AP --- Sent from Mailbox https://www.dropbox.com/mailbox for iPhone On Mon, Mar 10, 2014 at 8:57 AM, Fred Goldstein fgoldst...@ionary.com mailto:fgoldst...@ionary.com wrote: Very interesting, Chris, thanks If the latency is going up to 200-400 ms. and there are no other buffered network elements in the path, then it would seem to me that the ePMP has a very serious case of bufferbloat. This is sometimes done because it makes the radio seem to perform better on artificial speed tests (as it did), to the severe detriment of real-world performance. Nowadays, it's inexcusable. Are there any settings to control buffer sizes? Can someone find out from Cambium how much buffer is in there? On 3/10/2014 3:26 AM, Chris Fabien wrote: I spent some time tonight working with a couple ePMP radios on a test link and thought I'd share some results since I didn't get much feedback when I asked about this use case a couple weeks ago. Setup The link is a 7.5 mile link in a fairly noisy area, it has 2ft ubiquiti rocket dishes with RF Armor shield kits and formerly had normal Rocket M5 radios. Mikrotik CCR on one end and RB450 on other end. Evaluated latency and throughput between the two routers using the RouterOS bandwidth test. Used 20mhz channel throughout test. On a noisy frequency where the link had been running, about -75 noise floor, the Ubnt link would pass around 40 mbps aggregate with low latency 10ms. The ePMP would pass about 70mbps with stable 18ms latency, but performance was inconsistent when changing direction (tx/rx/both) - almost like the noise was little higher in one direction and affecting link stability when I tried to run traffic in that direction. It seemed a little less stable overall on that freq than the Ubnt radios.
[WISPA] Air Router
What is the best way to setup an Air router, bridge, router, soho router? I furnish them to my clientsI have set some of the them up as soho router, but now I have the fallbak IP 192.168.10.1 at the clients side of the radio. Thanx for your help NGL If you can read this Thank A Teacher. And if it's in English Thank A Soldier! flag.gif___ Wireless mailing list Wireless@wispa.org http://lists.wispa.org/mailman/listinfo/wireless
