You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm looking for a way to offer multiple service classes. This most likely means different commit rates, not any sort of 'priority' (premium plan demand doesn't cut in line, it just claws back the extra).
I was thinking, what about having an integrations file integrationUISPserviceclass.csv that could include the service plan name from UISP and the ratio of max vs commit or maybe a multiplier for burst on that plan. UISP actually has a burst option so that could be used as well, setting the plan speed as the commit and the burst as the limit.
Basically a means to alter the HTB allocations for each child queue based on service class.
~~
some rational to this request. I would rather end users USE the service, get their data and get off the wire sooner. I'm currently selling a number of 25x5 (prov 30x7) as a base line package so that they don't use up service that higher speed plans would like. In the current model of libreqos as well as other products, it's basically just the service speed that it uses in the HTB or the commit is a fixed % of that speed. So to let those 25x5 users use up what's available on the AP when there's excess capacity, they have to have a higher speed plan, however for the cheaper price I really need them to get dialed back to their commit rate when the AP is under pressure.
Might look like
20x 25x5 users
5x 100x20 users.
mostly idle AP, but one of the 25x5 users is pulling in a game update. I would like to offer them access to the 100 speed plan since it's available.
however, if a couple of the 100x20 users pop on, I need to pull the 'extra' given to the basic plan back to satisfy the premium package.
Further, I would like to give the 100x20 users access to basically the AP's capacity when it's available. So if it's a 160M capable AP, then I probably want them to have a 150x50 commit 100x20, and the base users have a 100x20 commit 25x5 plan.
I find that fairly often I'm looking at APs that have 1-2 users at max plan speed but airtime on the AP is like 25% and the head end is also at 25%. Why not make this available. I'd likely offer it as a minor upgrade on a plan, ie get the 25x5 standard plan or for 5-10 get the 'boost' version of that plan, sort of a in-between to the next higher plan.
The text was updated successfully, but these errors were encountered:
I'm not sure if I can answer that. Can you change the priority on the non-commit?
Honestly, I think Herbert's updates to bursting sort of do most of the work here. ie, residential might be on 10x5 commit and burst to 100x20 while business is on 20x20 burst 100x50.
I'm looking for a way to offer multiple service classes. This most likely means different commit rates, not any sort of 'priority' (premium plan demand doesn't cut in line, it just claws back the extra).
I was thinking, what about having an integrations file integrationUISPserviceclass.csv that could include the service plan name from UISP and the ratio of max vs commit or maybe a multiplier for burst on that plan. UISP actually has a burst option so that could be used as well, setting the plan speed as the commit and the burst as the limit.
Basically a means to alter the HTB allocations for each child queue based on service class.
~~
some rational to this request. I would rather end users USE the service, get their data and get off the wire sooner. I'm currently selling a number of 25x5 (prov 30x7) as a base line package so that they don't use up service that higher speed plans would like. In the current model of libreqos as well as other products, it's basically just the service speed that it uses in the HTB or the commit is a fixed % of that speed. So to let those 25x5 users use up what's available on the AP when there's excess capacity, they have to have a higher speed plan, however for the cheaper price I really need them to get dialed back to their commit rate when the AP is under pressure.
Might look like
20x 25x5 users
5x 100x20 users.
mostly idle AP, but one of the 25x5 users is pulling in a game update. I would like to offer them access to the 100 speed plan since it's available.
however, if a couple of the 100x20 users pop on, I need to pull the 'extra' given to the basic plan back to satisfy the premium package.
Further, I would like to give the 100x20 users access to basically the AP's capacity when it's available. So if it's a 160M capable AP, then I probably want them to have a 150x50 commit 100x20, and the base users have a 100x20 commit 25x5 plan.
I find that fairly often I'm looking at APs that have 1-2 users at max plan speed but airtime on the AP is like 25% and the head end is also at 25%. Why not make this available. I'd likely offer it as a minor upgrade on a plan, ie get the 25x5 standard plan or for 5-10 get the 'boost' version of that plan, sort of a in-between to the next higher plan.
The text was updated successfully, but these errors were encountered: