OpenWrt Forum Archive

Topic: Traffic Shaping with OpenWrt

The content of this topic has been archived on 14 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hello,

I have been using custom-written script and using HTB to limit incoming and outgoing transfers from/to various IP addesses. i was allowed to assign multiple IP addresses to single class, thus limiting all of them, as in HTB limit was laid on class, not on IP.

Actually I have 100/50mbps and I use both IPv4 and IPv6. However, my ISP does not provide IPv6 addressing, so I'm using SIXXS service. The problem is that when I limit traffic to 100mbps, then I can exhaust only about 65mbps and I cannot use whole of my bandwidth.

I heard about qos-scripts and sqm-scripts. Both seem to use Codel instead of HTB.
Can you tell me which one should I choose and how to configure it to achieve the following goals:
*) limiting both IPv4 and IPv6 (2 different interfaces)
*) limiting both incoming and outgoing transfers (2 different interfaces)
*) setup 2 classes per user (for download and upload) and assign both IPv4 and IPv6 addresses to it, so that user cannot exhaust more than specified bandwidth simultaneusly for both IPv4 and IPv6
*) do not limit transfers within LAN (at least for IPv4)
*) assign a default class for all not specified IPs when bandtwidth would be limited to 64kbps.

Do you have any examples of such working configuration?
Thanks!

(Last edited by belliash on 7 Apr 2015, 11:45)

Hi belliash,

belliash wrote:

Hello,

I have been using custom-written script and using HTB to limit incoming and outgoing transfers from/to various IP addesses. i was allowed to assign multiple IP addresses to single class, thus limiting all of them, as in HTB limit was laid on class, not on IP.

Actually I have 100/50mbps and I use both IPv4 and IPv6. However, my ISP does not provide IPv6 addressing, so I'm using SIXXS service. The problem is that when I limit traffic to 100mbps, then I can exhaust only about 65mbps and I cannot use whole of my bandwidth.

        Most likely you are running against your router's cpu limits, htb is quite costly and many home routers run out of "steam" around 60 to 70 Mbps; so this might be your primary issue. For testing set the shaping rates such that the sum of ingress and egress does not exceed 60 Mbps (then the shaper at least has a dance of working as expected, albeit slow)

belliash wrote:

I heard about qos-scripts and sqm-scripts. Both seem to use Codel instead of HTB.

        Codel or fq_codel is not a replacement for a shaper like HTB, but rather a replacement for either pfifo_fast or sfq as leaf qdisc. sqm-scripts uses HTB as shaper and fq_codel as leaf qdiscs by default, qos-scripts uses HFSC as shaper and fq_codel as leaf qdisc; both have similar CPU demands, and both work well within their limits.

belliash wrote:

Can you tell me which one should I choose and how to configure it to achieve the following goals:
*) limiting both IPv4 and IPv6 (2 different interfaces)

        qos-scripts does not handle IPv6 traffic well at all; sqm-scripts does work for IPv4 as well as IPv6. qos-scripts can only be activated on a single interface, sqm-scripts can be established on multiple interfaces concurrently.
        Note that it can get tricky to teach a shaper to shape the cumulative traffic on two unrelated interfaces, but often one can establish the shaper on the physical interface the links to the modem, which in effect will balanced the traffic for all meta-interfaces traveling over that physical interface.

belliash wrote:

*) limiting both incoming and outgoing transfers (2 different interfaces)

        Both qos-scripts and sqm-scripts do this quite well with the help of IFB devices.

belliash wrote:

*) setup 2 classes per user (for download and upload) and assign both IPv4 and IPv6 addresses to it, so that user cannot exhaust more than specified bandwidth simultaneusly for both IPv4 and IPv6

        Neither qos-scripts nor sqm-scripts are setup to do this, you will need to code your own scripts to that; but please go ahead and test both qos- and sqm-scripts first as many people report that both work quite well for a number of scenarios where before more elaborate scripts seemed required. In other words only elaborate if you have no other choice wink

belliash wrote:

*) do not limit transfers within LAN (at least for IPv4)

        Both qos- and sqm-scripts have you covered here, unless you set up the shaper on the router's lan interface instead of the wan interface.

belliash wrote:

*) assign a default class for all not specified IPs when bandtwidth would be limited to 64kbps.

        This looks like requiring manila coding again.

belliash wrote:

Do you have any examples of such working configuration?
Thanks!

        I would humbly recommend to test whether qos- or sqm-scripts do not already work well enough, and if not sqm-scripts allows to easily create your own scripts and hook them into the LUCI Gui, you could even use /usr/lib/sqm/sinple.qos as your starting point wink

Best Regards
        M.

@moeller0: Thank you very much for your response.
I was using this QOS rules on my TpLink WDR4300 and they worked quiet good. Recently I have migrated mi config to WRT1900AC (DualCore 1.2GHz ARM). So I suspec its not related to CPU power, especially that I dont see load on this router.
When I set limit to 50mbps, then I get around 45mbps. If i set the limit to 100mbps then I got only ~65mbps. If I increase the limit to 150mbps then it serves around 90mbps.
On my previous router (TPLink) I got ~10-11MiB/s, what gives around 80-90mbps. All my QOS rules have been migrated. I dont understand why more powerful router gives around 30mbps lower transfers...

Anyone? Any ideas?

Hi bullish,

belliash wrote:

@moeller0: Thank you very much for your response.
I was using this QOS rules on my TpLink WDR4300 and they worked quiet good.

belliash wrote:

        Well, maybe if you posted your script someone might be able to look closer at it? The more detail the better wink

Recently I have migrated mi config to WRT1900AC (DualCore 1.2GHz ARM). So I suspec its not related to CPU power, especially that I dont see load on this router.

belliash wrote:

        From my observation it is a bit tricky to assess the CPU load on a openwrt router as often a lot is happening in soft IRQs, so the easiest way to rule out CPU load is to use netperf-wrapper's RRUL test while looking at the output of "top -d 1" run on the router, basically looking at the idle percentage, pif idle is (close to) zero the CPU is maxed out. You probably know this already, but for the sake of people finding this thread I want this to be clear wink

When I set limit to 50mbps, then I get around 45mbps. If i set the limit to 100mbps then I got only ~65mbps. If I increase the limit to 150mbps then it serves around 90mbps.

belliash wrote:

        This could be the sign of a router running against its cpu limits, or in case you use a policer for ingress just the inherent "choppiness" of a policer.

On my previous router (TPLink) I got ~10-11MiB/s, what gives around 80-90mbps.

belliash wrote:

        Interesting, I had thought a wdr4300 would run out at around 70Mbps combined upload and download shaping, so your old results are quite good.

All my QOS rules have been migrated. I dont understand why more powerful router gives around 30mbps lower transfers...

        Well, could it be that you used two different openwrt versions on the to-link and the belkin? That might explain some differences...

Best Regards
        M.

Another consideration for the WRT1900AC... The firmware has been improving rapidly in the last week. People report significant gains in data transfer speeds, as well as dramatic improvements to wifi performance and reliability.

You'll be on the bleeding edge, but it sounds as if this router's firmware is coming out of the weeds. Some pointers into the lengthy topic:

https://forum.openwrt.org/viewtopic.php … 24#p271824
https://forum.openwrt.org/viewtopic.php … 35#p271835
https://forum.openwrt.org/viewtopic.php … 05#p271905

If you have been using a recent build (after r45272 and before r45321) read about the workaround for preserving your configuration.
https://forum.openwrt.org/viewtopic.php … 51#p271851

The discussion might have continued from here.