I agree, I would rather have the lower modulation SMs penalized, instead of eating up all the airtime.
On Fri, Nov 13, 2015 at 3:23 PM, George Skorup <[email protected]> wrote: > We rarely use CIR. We will sometimes give business-class customers a > little bit of CIR so their VPN won't break, etc. > > We aim for a minimum 6X on every customer, but we will occasionally accept > a borderline 4X-6X SM link because sometimes there's no choice. A little > degradation causing those links to sit at 4X during Netflix time really > drags the sectors down. So, I think it would be beneficial to dynamically > penalize the lower modulation SMs instead of letting them sit there and eat > up all the air time. > > My $0.02. > > > On 11/13/2015 10: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 >> > > >
