I promise I don't have a filter setup just to look for my name. :) Yes, you nailed the conundrum here. I think up to this point, I've maybe been too much of a stickler for "make it easy to use and fully understandable" assuming people would want a mixture of both. The problem with that is, they dynamics are potentially always changing. So we've been coming up with ways to mitigate those concerns, when at the end of the day, most people would probably just run one method or the other.
If you are using CIR, and you have committed a lot of data to a low modulation user, then that user would most definitely be adversely affecting the sector. And enabling this new option would correct it, but then you are no longer serving that CIR that was presumably given to that customer for a reason (data plan, business customer, etc). We know you are all savvy enough to know you don't guarantee data rates to a low mod rate user unless you absolutely have no choice, but if you were to have that scenario, and went to an airtime CIR (would that be called CAR?) , then the issues are obvious. And if/when we would go to supporting both methods on one sector (choose method per SM), then planning CIR/CAR could be quite difficult. Of course, if we assume that the rate achieved upon the install is where the user would stay, then it would be easier because you could build the CIR/CAR plan for the sector as the installs occurred, and periodically go back and validate the distribution. Anyways - yes there is something in the works, and some of it is already in there today, just not active. :) -Aaron -----Original Message----- From: Af [mailto:[email protected]] On Behalf Of Adam Moffett Sent: Saturday, November 14, 2015 10:52 AM To: [email protected] Subject: Re: [AFMUG] LTE Speeds I invoke the name of Aaron Schneider and he appears! I am the dungeon master of AFMUG! I see your point. In a nutshell the problem is that we are marketing bits per second, but what we actually have to hand out is air time. We can try to deliver the bps that everybody wants, but then we might not be distributing air time in an efficient way. We can distribute air time in an efficient way, but then some people won't get the bps they want. IMO, it is OK to to simply switch on equal time scheduling for whole AP. Consider Eric Muehleisen's thread from last week. Subject: "450 frame utilization and performance issues". He's got a whole AP that doesn't go above 23mbps. Trying to deliver full speed to every customer no matter how bad their signal is might mean that everybody suffers. He also has an external system capping speed (as do a lot of other people). I have a suspicion that distributing equal airtime rather than equal bits per second would interact more favorably with an external system like that. Though you're probably in a better position than me to comment on that. On 11/13/2015 11:04 AM, Aaron Schneider wrote: > The Canopy scheduler operates with a combined priority based scheme and a > round robin based scheme. As has been covered here in the past, the > scheduling priority is as follows: 1) High Priority CIR 2) Low Priority > CIR 3) Bcast/Mcast CIR 4) High Priority 5) Low Priority 6) Bcast/Mcast. > > If you don't oversubscribe your CIR, then things are fine. But, that is very > tricky when you assume CIR based on one data rate (say 8x), and the actual > link requiring that CIR is different (say 4x). Now, that SM is requiring > twice as much frame time to meet that CIR as you may have planned. This goes > to the concept of allocating capacity based on throughput, and it is > generally how Canopy works. The round robin comes in so that one SM can't > take everything on its own, it will try to be fairer, but, it will still do > everything it can to honor the CIRs of each SM in every frame. > > We do have a feature in the works where we flip that a bit where the CIR > becomes airtime based so generally speaking, you are guaranteeing air time > and not throughput. The idea is that you will assign a CIR based on a given > rate, say 8x, and if the SM drops (or can only ever achieve) 4x, then they > will get half the data rate because they are only allowed the same amount of > time as if they were 8x. The underlying concept is easy, it is the external > interface and making it easily understood and helping you stay out of trouble > with configurations that is difficult. If it is OK to just say turn on the > option, but then not be able to predict the throughput, that's one thing, but > if you have a customer that needs a given throughput no matter what his data > rate becomes, and other customers that are OK with just having limited > airtime access, then the overall planning of CIR becomes tricky to not > over-commit. > > So what would you all prefer? An option per sector to enforce CIR in a given > way for all SMs? Or enforce CIR in a selectable way (throughput vs. air > time) per individual SMs on a given sector? > > Regards, > -Aaron > > > > > -----Original Message----- > From: Af [mailto:[email protected]] On Behalf Of Adam Moffett > Sent: Friday, November 13, 2015 8:28 AM > To: [email protected] > Subject: Re: [AFMUG] LTE Speeds > > Maybe it already does? They say capacity is allocated proportional to > sustained rate when there's contention....do they mean "capacity" in bps or > "capacity" in time slots. I'm thinking it's the latter because I have > observed that if you improve the data rate of an individual SM he'll get > more, which makes sense if the SM's capacity allotment is measured in > timeslots rather than bits. > > Where's Aaron Schneider when you need him? > > > On 11/13/2015 9:14 AM, Craig Schmaderer wrote: >> Cambium if it is at all possible please please add this to the 450!!!!! >> >>> On Nov 12, 2015, at 4:51 PM, Dan Petermann <[email protected]> wrote: >>> >>> LTE can be set for equal time or equal rate. Equal rate will drag down the >>> thruput of all users. >>> >>> Equal time will only impact the user with a poor signal. If everyones >>> signal is great and one users radio signal is bad, that user only gets the >>> thruput that can be crammed into his timeslot because his modulation is >>> low. Everyone else continues as normal. >>> >>> At least that is my understanding. >>> >>> >>>> On Nov 12, 2015, at 3:01 PM, Adam Moffett <[email protected]> wrote: >>>> >>>> ....any system with 20mhz channels + two chains + 256QAM can claim 100mbps. >>>> Getting past that is going to be carrier aggregation (bigger channels) and >>>> MU-MIMO. >>>> >>>> 5x20mhz channels aggregated = 500mbps. >>>> >>>> MU-MIMO can theoretically double capacity. So there's your 1gig. >>>> I'm not clear on how far you can count on MU-MIMO. In theory it sounds >>>> promising. >>>> >>>> ....and yes, one person at MIMO-A QPSK is going eat up many times the >>>> capacity of a person at 256QAM MIMO-B no matter what wireless system >>>> you're using. The best defense against that will be don't install bad >>>> connections. Nothing new there. >>>> >>>> If you're going to use 100mhz, you could of course install 5 AP's of your >>>> choice and claim you have a 500mbps system. >>>> >>>>> On 11/12/2015 4:47 PM, Matt wrote: >>>>> Hear talk of these 50 - 100+ mbps speeds per user and eventually 1 >>>>> gbps. How can LTE do that in 10 to 20 mhz of spectrum? I assume >>>>> if you are offering 50 mbps package in a sector its safe to assume >>>>> at prime time there are going to be at the very least 10 people >>>>> using it in that sector at the same time? Also assume some have >>>>> less then perfect connections to the tower using more air time.
