So doing the same, you could have interval scripted speedtests to define your rate?5 second speedtest every 10 or 15 minutes or something of that nature, use the result to define your speed?
Thats what that one system does with the brains and nodes or whatever, I cant remember what its called, I havent heard anybody talk about it in a while On Mon, Nov 9, 2015 at 2:16 PM, Joshaven Mailing Lists <[email protected]> wrote: > I have a different approach to recommend that I believe turns the can’t > into a can. > > What you can do is ensure that the type of service mark ( DSCP ) is set in > accordance with your preference. Then you can setup QoS on any of your > radio links such that they prioritize the important traffic. That way when > the deliverable bandwidth is unexpectedly low the right traffic makes it > and the other traffic is held back or dropped. > > If your looking for a simple miens of setting the DSCP, you can trust the > DSCP setting from your client by adding connection marks to the connections > then on ingress to your network you can remark the traffic in those > connections. ( You’ll find that most traffic that has transversed the > internet has had the DSCP bits reset so you don’t want to trust from the > internet ). Now, trusting your client’s DSCP marks is a quick and dirty > way and trusting anyone that is not you is generally not a good idea so you > may want to have override rules or other miens of altering the DSCP but > that is a bigger conversation. > > Ultimately, QoS is all about limiting speed so asking how to use QoS > without limiting speed is kind of the wrong question. QoS is like a > traffic light, the end result is faster because traffic is limited when it > is needed. If you set the DSCP bits on network ingress and ensure all of > the bottle necks are QoS enabled then you will have most of what you want > in regards to ensuring that VoIP and other sensitive services are working > well. Beyond that you can limit the user’s overall speed based on the sold > package and for extra credit limit their TCP traffic before the small > packet UDP (VoIP, games, etc). > > > Sincerely, > Joshaven Potter > MTCNA, MTCRE, MTCWE, MTCTCE, UACA > Google Hangouts: [email protected] > Cell & SMS: 1-517-607-9370 > [email protected] > > > > On Nov 6, 2015, at 11:47 AM, Dennis Burgess <[email protected]> > wrote: > > Nothing in SFQ etc can help, that system is based on how much bandwidth do > you have; not how much you have at the current time. If you are using a MT > metal9 or something like that yes, you can use the data rate to change the > queues, this would be the simplest, or better yet, use NV2 to do your > prioroziation on the radios. If you are using something else that has a > dumb queue,. Then you are limited by that. > > Dennis Burgess, CTO, Link Technologies, Inc. > [email protected] – 314-735-0270 x103 – www.linktechs.net > > *From:* Af [mailto:[email protected] <[email protected]>] *On > Behalf Of *Christopher Gray > *Sent:* Friday, November 6, 2015 10:45 AM > *To:* [email protected] > *Subject:* Re: [AFMUG] Mikrotik fair queues over a variable speed link? > > I'm not sure it can work without some feedback from the radio itself. > Without some mechanism to slow traffic down between the router and the > radio, all traffic will pass through the queuing system of the router and > then be passed at link speed to the radio. Then the radio will have to deal > with the queue. > > I'm still going to play with the Mikrotik Stochastic Fairness Queuing, > but I'm not convinced it will help much. > > Manipulating closed loop communication without control over all of the > parameters is hard, but I still think there is a way. I like the idea about > adjusting the peak speed based on ping time. Perhaps some adjustment could > be made while checking the radio modulation. I like what Dennis > suggested... a speed test. Perhaps one could pass low priority traffic (so > it does not negatively affect existing traffic), measure the total > throughput on the link on a periodic basis, and adjust the queue > accordingly. On the other hand, it may be easier to just raise the antennas > 30'. > > I'd still like to find a solution. If I do, I'll share. > > -Chris > > On Fri, Nov 6, 2015 at 11:05 AM, Adam Moffett <[email protected]> wrote: > > If there's a way that works, I'd be interested also. > > What I know you CAN do is put higher priority on shorter connections. You > mark packets based on bytes transferred in a connection and give higher > priority to connections that haven't yet moved more than X bytes (maybe > 5,000,000 or 20,000,000). > > Maybe you can't make everyone's streaming work that way, but you can make > sure their web browsing and email works. > > > On 11/5/2015 4:28 PM, Christopher Gray wrote: > > Is there a way to implement a fair queue system [like PCQ but] over a > variable speed / flexible frame link without significantly limiting the > overall link speed? I have an area that is being served with a NLOS > backhaul link having variable peak speeds. > > I'm working on the improved backhaul location, but it will still be a few > months. > > Thanks - Chris > > > -- If you only see yourself as part of the team but you don't see your team as part of yourself you have already failed as part of the team.
