1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Please refresh how to use lower limit in QOS

Discussion in 'Tomato Firmware' started by fefrie, Apr 21, 2014.

  1. fefrie

    fefrie Serious Server Member

    My internet connection is a 7500kbps down sustained with a 512mb up sustained with a possibility of a 25000 momentary burst on initial connections.

    I understand setting max limits on classes so they don't exceed a certain throughput.

    Can someone tell me if I'm wrong when I say:

    "To guarantee minimum throughput to certain classes, place those classes higher and set the minimum throughput for incoming to a level you require."

    I know that this reasoning is flawed somehow.

    I'm not quite sure how the lower limit setting works.
     
  2. cloneman

    cloneman Networkin' Nut Member

    A good explanation was provided to me by porter here:
    http://www.linksysinfo.org/index.ph...rial-and-discussion.28349/page-10#post-227594

    Basically, High classes borrow/steal bandwith from low classes, which is good. However, we want our low classes to retain some amount of bandwidth, not be completely starved. So we used the left-hand column to specify a minimum bandwith that will never be dropped for the benefit of another class. This should be a conservative value in most cases, about 5% in most case, perhaps a little more for certain classes which you want to retain more capacity in situations where many high priority classes are competing for bandwidth.

    You don't want the sum of your left-side columns to exceed 100%, because then you could fall into a situation where each class is entitled to it's share and there's no class to borrow bandwidth from for your high priority classes.

    Yet another example to understand this: the minimum is useless for your #1 class, because there's no need to "reserve" bandwidth for it, as none of the other classes are allowed to steal from it (in theory... I still give my #1 a minimum, because I don't know how stuff REALLY works down deep and this "feels" better to me). The minimum however is important for your middle and low classes, because upper classes can otherwise borrow all of their bandwidth leaving them with ridiculously slow performance without good reason.
     
    Last edited: Apr 22, 2014
  3. fefrie

    fefrie Serious Server Member

    That is a great refresher link. Thanks so much.

    In addition to what you post, what I got from that thread is

    the order of categories and classification both matter. Category #1 has a higher priority than category #2 and so on. Traffic flowing through the router will walk, step by step, through the rules in order (1, 2, 3, 4, etc.) until they're classified.

    So when I go to QOS and under the "View Details" If I have 40 rules, and under connection I see which rules being used as something like 1, 17, 30, 31, 33,34 and nothing else, I should move those rules up the ladder so to speak so those packets don't get 'washed' through so many rule classifications.

    If I do it properly then, I will see the rules that are applied should be 'closer to the top' (1,3,5,6,7,8,11,13) which means that there is more efficient analyzing of the packets.

    An example of more efficient rule organization would be to have any rules concerning VOIP near the top so that packets get processed fast, in addition to the high placement on the classification category.

    And lastly, L7 Rules in the Classification tab should be placed on the bottom since they are CPU intensive.
     
  4. Porter

    Porter LI Guru Member

    The problem with those L7 filters is that most of them match traffic on port 80 so they have to be placed before the actual port filter for port 80. At the same time you want to minimize the traffic the L7 filters are seeing, because they are cpu expensive. Another thing you need to keep in mind is that once a filter matches traffic, no other filter can match. So the order already is quite good and has been revised numerous times.
     
  5. fefrie

    fefrie Serious Server Member

    That seems to make sense.

    I've moved all the L7 Filters to the bottom and I don't see them being used very often (if at all).

    On Toastman's firmware, they were already part of the list of classifications. Since I don't see them being used very often, I may start deleting them. The ones I am looking at are the youtube-2012, flash and http L7 Filters.

    I rarely if ever see them being used.
     
  6. Porter

    Porter LI Guru Member

    If you are using a recent Toastman firmware, those L7 filters already have been at the bottom. That's why I'm not really sure if you just disabled them by putting those for youtube und flash behind the port 80 filters...

    You can use this command to check whether those L7 filters see any traffic:
    Code:
    iptables -vL L7in
     

Share This Page