Just speculating, but since the AP is doing this in firmware, and we know the 
450 AP has CPU horsepower limitations (compared to 450i and 450m), I wonder if 
it starts struggling to do QoS smoothly when it just barely has enough CPU 
cycles to just forward the data.  But even so, why is the OP only seeing this 
on speedtest.net?

 

From: AF <af-boun...@af.afmug.com> On Behalf Of David Sovereen
Sent: Monday, December 10, 2018 12:24 PM
To: AnimalFarm Microwave Users Group <af@af.afmug.com>
Subject: Re: [AFMUG] speedtest.net and Canopy/Cambium QOS / burst bucket

 

I don’t agree either.

 

The AP is the ONLY device that knows the maximum throughput at any given point 
in time because the max throughput varies second by second based on what SMs 
are talking, their modulation, their max throughput, etc.  Shaping a port to 
its theoretical max only has an effect when the SMs being serviced by the AP at 
that exact moment are at the max modulation with no retransmissions. Anything 
less than perfect efficiency will allow more traffic to go to the AP than the 
AP can deliver to the SMs behind it.  Shaping a port to less than its 
theoretical max unnecessarily slows traffic when conditions are right for 
maximum throughput.

 

It is my opinion that it is best to mark packets with priorities and let the AP 
shape the traffic.  If the AP’s scheduler/shaper isn’t good, then that needs to 
be fixed in the AP.  Yes, Preseem can monitor queue lengths and can discern 
when a flow maxing out the underlying link and drop packets to slow the flow 
down.  So can the AP. 

 

David Sovereen

 

Mercury Network Corporation

2719 Ashman Street, Midland, MI 48640
989.837.3790 x151 office | 888.866.4638 toll free |  989.837.3780 fax

 

Telephone  |  Internet  |  Security Alarm Monitoring

 

 <mailto:david.sover...@mercury.net> david.sover...@mercury.net

www.mercury.net <http://www.mercury.net/> 








On Dec 10, 2018, at 12:16 PM, Adam Moffett <dmmoff...@gmail.com 
<mailto:dmmoff...@gmail.com> > wrote:

 

Interesting claim.  I can't say I agree.

On 12/9/2018 8:56 PM, Darin Steffl wrote:

All testing done by many wisp's shows that shaping at the radio/CPE or AP is 
about the worst way to do it. 

 

Leads to huge slowdowns when the customer maxes their plan and other weird 
issues, maybe like what you're seeing. 

 

I'd recommend shaping at your core, before it hits your backhaul network. We 
use preseem and it's a gem 

 

On Sun, Dec 9, 2018, 7:18 PM Kurt Fankhauser <lists.wavel...@gmail.com 
<mailto:lists.wavel...@gmail.com>  wrote:

no ken i have not tried cranking up the QOS in the radio itself, maybe i will 
try that

 

On Sun, Dec 9, 2018 at 4:01 PM Ken Hohhof <af...@kwisp.com 
<mailto:af...@kwisp.com> > wrote:

Do you see the same thing even if you crank up the QoS settings as far as they 
will go?  Trying to determine if it’s Cambium’s QoS mechanism or something 
else.  We enforce speed tiers outside the radios so I don’t have much 
experience with how well or poorly Cambium’s QoS implementation works and 
whether there are any quirks that might interact badly with Ookla based 
speedtests.

 

From: AF <af-boun...@af.afmug.com <mailto:af-boun...@af.afmug.com> > On Behalf 
Of Kurt Fankhauser
Sent: Sunday, December 9, 2018 11:18 AM
To: af@af.afmug.com <mailto:af@af.afmug.com> 
Subject: Re: [AFMUG] speedtest.net <http://speedtest.net/>  and Canopy/Cambium 
QOS / burst bucket

 

Also here is AP downlink utilization graph for last 24 hours. Clearly AP is not 
overloaded only got up to beyond 20% for a very short period of time.

 

On Sun, Dec 9, 2018 at 12:13 PM Kurt Fankhauser <lists.wavel...@gmail.com 
<mailto:lists.wavel...@gmail.com> > wrote:

Ken there is no problem selling 50meg plans on original 450 AP's running 30 mhz 
channels that only have a dozen low usage clients. 75/25 downlink ratio and 
30mhz channels should yeild at least 100mbps down on linktests in 8x. Once you 
start to load up the AP's its not the original 450 SM's thats the problem its 
the AP itself as those things give out at about 70'ish mbps down (even though 
the link tests show there is more capacity). At that point you just switch the 
AP out with a 450i and you can take advantage of the beyond 70mbps downlinks. 

 

My original problem is not related to running out of capacity on the AP as I am 
clearly able to get the bandwidth there with the www.openspeedtest.com 
<http://www.openspeedtest.com/>  site as well as Mikrotik Btest (see attached 
pic). Yes the attached pic is a Mikrotik router doing a TCP BTEST through an 
original 450SM and original 450AP that has 15 clients attached to it! 

 

On Sun, Dec 9, 2018 at 9:55 AM Ken Hohhof <af...@kwisp.com 
<mailto:af...@kwisp.com> > wrote:

OK, this comment conflicts with your report that the problem only shows up when 
testing with speedtest.net <http://speedtest.net/> .  But still, I have to 
question the wisdom of selling 50M plans using Cambium 450.  That’s a lot of 
throughput for a multipoint platform, and is only going to work if the stars 
are aligned.

 

Is this a 450, 450i, or 450m AP?  What about the SM?  You could be running into 
CPU limitations on packets per second.

 

Are you using 20,30 or 40 MHz channel width?  What down/up ratio?  If your 
configured for 20 MHz and 75%, you’re selling one subscriber almost the total 
capacity of the AP.

 

Is this subscriber at 8x modulation?  Do you have other subs on the AP at lower 
modulations, and if so, are their QoS settings a lot lower so they get lower 
priority, or are you using the new SM priority features?  A bunch of subs at 2x 
or 4x can eat up AP capacity pretty quick.  I’m assuming this isn’t a 450m with 
MUMIMO.

 

Are you monitoring/graphing AP frame utilization?  This will help diagnose if 
the AP is running out of capacity and having to decide which SM gets the 
available over-the-air frames.

 

My impression (could be wrong) is that the Ookla speedtest doesn’t take a 
goodput approach, it seeks out the highest transmit rate at which the packet 
loss is tolerable.  I also saw a claim by one of the bandwidth management 
products that 450 and ePMP QoS work differently, 450 by dropping packets, and 
ePMP by buffering them, I don’t know if that’s correct.  It could be that 
running 450 QoS so close to total AP capacity, there is some kind of clumping 
of packet delivery going on that speedtest.net <http://speedtest.net/>  
interprets as having hit the max connection speed.

 

That said, I believe I have seen 50 Mbps speedtest.net <http://speedtest.net/>  
results using a 450 SM at 8x modulation off a lightly loaded 450 AP, although 
that seems like it would be pushing the CPU limits of both AP and SM.  Better 
combination would a 450i or 450m AP with a 450b SM.  I don’t sell 50M plans, at 
that point I would consider that I need a dedicated PTP link to the customer 
and they are buying DIA service.  But even at 25M, I would use a 450b SM rather 
than an uncapped 450SM or an upgrade key.  Maybe everyone has switched to 450b 
by now, but we still have mostly the regular 450 SMs.  Not gonna go out and 
swap them all,  especially since a lot of them were swaps from FSK or 430.  
Tired of throwing away $250 SMs every few years.

 

 

 

From: AF <af-boun...@af.afmug.com <mailto:af-boun...@af.afmug.com> > On Behalf 
Of Kurt Fankhauser
Sent: Saturday, December 8, 2018 9:43 PM
To: af@af.afmug.com <mailto:af@af.afmug.com> 
Subject: Re: [AFMUG] speedtest.net <http://speedtest.net/>  and Canopy/Cambium 
QOS / burst bucket

 

here is burst bucket settings, selling customer 50M plan 

 

On Sat, Dec 8, 2018 at 7:57 PM Sean Heskett <af...@zirkel.us 
<mailto:af...@zirkel.us> > wrote:

What are your qos settings on the cambium radios?

 

We don’t see this behavior at all so I’d be glad to help you work through it. 

 

-Sean

 

On Sat, Dec 8, 2018 at 5:07 PM Kurt Fankhauser <lists.wavel...@gmail.com 
<mailto:lists.wavel...@gmail.com> > wrote:

Is there something with Canopy/Cambium Radios (PMP450) that gives reduced speed 
results when done behind SM's with speedtest.net <http://speedtest.net/> ?

 

I always tell customers to use www.openspeedtest.com 
<http://www.openspeedtest.com/>  for the most accurate download speeds because 
my customers on the 50meg plans running 450 SM's are wanting to see proof that 
their connection is getting that and openspeedtest.com 
<http://openspeedtest.com/>  is the only test site that will show near 50 meg 
tests. Go right over to speedtest.net <http://speedtest.net/>  and get in the 
20's on the testing. This has been a problem for me for years. I just tell the 
customer that we do all testing on openspeedtest.com 
<http://openspeedtest.com/>  and any other test site is overloaded which is why 
results are slow so we do not support those other sites. Now if i plug directly 
into switches at towers with my laptop or am on a connection that is behind an 
AF5X radio then speedtest.net <http://speedtest.net/>  works perfectly fine and 
i can easily get tests of 150-200mbps.

 

So this appears to be isolated to Cambium 450 radios and only on certain 
speedtest sites. All CPE's are in bridge mode and have Mikrotik routers on 
customer sites. And unlimited throughput keys on the SM's. Also I must add I 
can do a MT Btest using TCP and still get the 50mbps test over the 450 SM so 
what the heck is going on with speedtest.net <http://speedtest.net/>  and 
Cambium 450 radios??????

-- 
AF mailing list
AF@af.afmug.com <mailto:AF@af.afmug.com> 
http://af.afmug.com/mailman/listinfo/af_af.afmug.com

-- 
AF mailing list
AF@af.afmug.com <mailto:AF@af.afmug.com> 
http://af.afmug.com/mailman/listinfo/af_af.afmug.com

-- 
AF mailing list
AF@af.afmug.com <mailto:AF@af.afmug.com> 
http://af.afmug.com/mailman/listinfo/af_af.afmug.com

-- 
AF mailing list
AF@af.afmug.com <mailto:AF@af.afmug.com> 
http://af.afmug.com/mailman/listinfo/af_af.afmug.com

-- 
AF mailing list
AF@af.afmug.com <mailto:AF@af.afmug.com> 
http://af.afmug.com/mailman/listinfo/af_af.afmug.com





 

-- 
AF mailing list
AF@af.afmug.com <mailto:AF@af.afmug.com> 
http://af.afmug.com/mailman/listinfo/af_af.afmug.com

 

-- 
AF mailing list
AF@af.afmug.com
http://af.afmug.com/mailman/listinfo/af_af.afmug.com

Reply via email to