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 [email protected] <mailto:[email protected]> www.mercury.net <http://www.mercury.net/> > On Dec 10, 2018, at 12:16 PM, Adam Moffett <[email protected]> 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 <[email protected] >> <mailto:[email protected]> 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 <[email protected] >> <mailto:[email protected]>> 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 <[email protected] <mailto:[email protected]>> On >> Behalf Of Kurt Fankhauser >> Sent: Sunday, December 9, 2018 11:18 AM >> To: [email protected] <mailto:[email protected]> >> 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 <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>> 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 <[email protected] <mailto:[email protected]>> On >> Behalf Of Kurt Fankhauser >> Sent: Saturday, December 8, 2018 9:43 PM >> To: [email protected] <mailto:[email protected]> >> 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 <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>> 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 >> [email protected] <mailto:[email protected]> >> http://af.afmug.com/mailman/listinfo/af_af.afmug.com >> <http://af.afmug.com/mailman/listinfo/af_af.afmug.com> >> -- >> AF mailing list >> [email protected] <mailto:[email protected]> >> http://af.afmug.com/mailman/listinfo/af_af.afmug.com >> <http://af.afmug.com/mailman/listinfo/af_af.afmug.com> >> -- >> AF mailing list >> [email protected] <mailto:[email protected]> >> http://af.afmug.com/mailman/listinfo/af_af.afmug.com >> <http://af.afmug.com/mailman/listinfo/af_af.afmug.com>-- >> AF mailing list >> [email protected] <mailto:[email protected]> >> http://af.afmug.com/mailman/listinfo/af_af.afmug.com >> <http://af.afmug.com/mailman/listinfo/af_af.afmug.com> >> -- >> AF mailing list >> [email protected] <mailto:[email protected]> >> http://af.afmug.com/mailman/listinfo/af_af.afmug.com >> <http://af.afmug.com/mailman/listinfo/af_af.afmug.com> >> > > -- > AF mailing list > [email protected] > http://af.afmug.com/mailman/listinfo/af_af.afmug.com
-- AF mailing list [email protected] http://af.afmug.com/mailman/listinfo/af_af.afmug.com
