OpenWrt Forum Archive

Topic: A qos script that really works!

The content of this topic has been archived between 1 Apr 2018 and 30 Apr 2018. Unfortunately there are posts – most likely complete pages – missing.

I tried both, and I'm not sure if I see any difference.
One thing that happened is that with ndb's scripts I had a huge latency for HTTP, but I suspect this has more to do with my ISP than anything else. I'm running Rudy's sripts now to see if the latency problem persists.

jp wrote:

I tried both, and I'm not sure if I see any difference.
One thing that happened is that with ndb's scripts I had a huge latency for HTTP, but I suspect this has more to do with my ISP than anything else. I'm running Rudy's sripts now to see if the latency problem persists.

Please let me know the results. I too believe its probably not related to nbd's scrripts. I know that I prefer the configuration format of nbd's scripts, but Rudy's scripts are so popular that there is surely some good reason people prefer them.

It seems ridiculous for us to support two QoS scripts in webif^2, so I am even considering just choosing one and going with it. We already have a page to configure Rudy's scripts, but it needs some work according to the author. Of course, if both scripts used a compatible configuration file format (or a translator existed) this wouldn't be an issue.

It seems ridiculous for us to support two QoS scripts in webif^2, so I am even considering just choosing one and going with it.

Well... I wouldn't say it's ridiculous. I think that since both are used by so many people, both could be supported (unless it makes thinks to complex for you, of course). You have a set of functions that are implemented in different ways for each script -- as if you were writing classes derived from an abstract one, I suppose?

-- jp

The loading and saving of the settings will have to be rewritten for nbd's scripts. We have the functions already there for nbd's config file format (thanks nbd) it just needs to be written.

jp, I do agree that in theory we can use a common page with abstracted load/save code.

As with everything, its a matter of work. So I suppose the final decision will come down to if anyone does this work or not smile. We'll do something with nbd's scripts, I guess.

I just installed rudy's QoS scripts. I measured my line speed at dslreports.com/stest and got 9120 down / 360 up. Then I put in the conf file 8200 down / 324 up (90% of measured max). Then I did the speed test again and found that my speed is now 5548 down / 297 up. Is this the normal behavior of QoS? I would expect it to be able to use the set bandwidth to its fullest since I do not have any other traffic.

I'll just install manually and get the necessary scripts off the router, but just FYI... trying to use the qos-re package in imagebuilder I get:

Unpacking qos-re...Done.
Configuring qos-re...env: /etc/hotplug.d/iface/20-qos: No such file or directory

Edit: however odd, the 20-qos script is in fact there when I flashed the firmware, so no matter... smile

(Last edited by phat_bastard on 19 Oct 2006, 21:20)

mcdonald wrote:

I just installed rudy's QoS scripts. I measured my line speed at dslreports.com/stest and got 9120 down / 360 up. Then I put in the conf file 8200 down / 324 up (90% of measured max). Then I did the speed test again and found that my speed is now 5548 down / 297 up. Is this the normal behavior of QoS? I would expect it to be able to use the set bandwidth to its fullest since I do not have any other traffic.

We'll assume these results are accurate (a big assumption for an internet bandwidth test). It is possible that the addition of the QoS scripts caused additional overhead that lowered your maximum sustained WAN throughput. You could test this theory a number of ways. One would be to disable any l7 filters, include ipp2p. Then see if the speed improves or not. Another possible, but less certain test would be to overclock your router and see if there is a proportional gain in throughput (assuming CPU and/or backplane clock speed is a limiting factor).

Hello,

I'd like to know if it s possible to dedicate 100Kb for the VoIP without knowing my bandwith.
I move a lot with my WRT, I dont want to always set the bandwith !!

Is it possible ??!!

Thank you

Bye

(Last edited by TeKa on 26 Oct 2006, 12:07)

Hi jf,

Just noticed your post, sorry about the delay(went without internet connection for 3 months due to some provider mess up...).

Adding a port number to the the ip address is an interesting suggestion. Will look into this for an upcoming release.

Rudy.

jp wrote:

Hi Rudy.
I've been using your package, and it works really well.

But is there a way to specify that traffic to/from a compination of IP and port should get into PRIO, for example?
I don't want to get all trafic from one IP as prioritized, because that computer also does FTP and download updates from MS, etc. On the other hand, I don't want to set all HTTP traffic to PRIO, because other computers do bulk HTTP transfers, and that would break QoS completely.

So... Would it be easy to add support for something like this?

PRIO="192.168.1.100:80"

That would be really great!

-- jp

Version 1.05 of qos-re is now available. It includes the option to specify a port number or port range along with an IP address. This will help prioritize traffic to and from a multipurpose server with different services, such as http and ftp, running concurrently.

Install with:

ipkg install http://files.eschauzier.org/qos-re_1.05_all.ipk

The changelog:
1. Added option to specify port number or port range with IP address based matching
2. Changed documentation in qos.conf to reflect new option

The hfsc version of the v1.05 script is also available, install with:

ipkg install http://files.eschauzier.org/qos-re-hfsc_1.05_all.ipk

The changelog is the same as for qos-re.

To obtain the new /etc/qos.conf file with updated documention on the new IP ports option, make sure you answer Yes during installation when asked to overwrite the existing file. Also, you may need to remove existing packages when installing a package with a new name (e.g. qos-re-hfsc over qos-re). In both cases the original /etc/qos.conf will be lost, so please make sure you save a copy of the current configuration file.

After modifying /etc/qos.conf, you will need to run qos-start to load the new settings. The command qos-stat is available to check the current QoS status.

The bare scripts and config file can be found here:
HTB version of the script: 20-qos-htb
HFSC version of the script: 20-qos-hfsc
Default configuration file for both versions: qos.conf

(Last edited by rudy on 30 Dec 2011, 10:00)

i would like to congratulate and say thank you to rudy for this great script.

i have a wifi internet at home (max 385kbps, slow actually) and i have to share it with a room mate. problem is that he leaves his pc downloading files from torrent sites all day leaving me a small portion of the bandwidth. i tried blocking p2p and said that the router was broken. now he's suspicious about it.

thanks to your script, now i can use the internet and set 10 percent of the whole bandwidth for p2p (even with many p2p connections, the combined download speed for p2p is just 38.5kbps).

here's my script:

TCP_BULK="0:"
UDP_BULK="0:"

TCP_PRIO="22 23 53 80 443 1863 5050"

tc class add dev $LAN parent 1:1 classid 1:10 htb rate $(($DOWNLOAD*1/10))kbit ceil ${DOWNLOAD*10/100}kbit burst $D_BURST cburst $D_BURST prio 0
tc class add dev $LAN parent 1:1 classid 1:20 htb rate $(($DOWNLOAD*1/100))kbit ceil $(($DOWNLOAD*5/100))kbit burst $D_BURST cburst $D_BURST prio 1

it's not that i hate p2p. i use it only when i have a very fast connection and i'm not causing any problems with other users sharing the same connection

regards......steve

(Last edited by stevevai on 4 Nov 2006, 10:17)

Good to hear the script is working for you!

Just for my information, what is the reason you made the changes to the two tc lines in the script? Didn't the default config work for you? With the default configuration, I'd expect the script to do exactly what you are looking for. In fact, it seems it would have the added benefit that when you are not using the shared internet connection, your roommate can run his p2p at near full speed, only to back off once you get online.

I am probably overlooking something, please let me know.

stevevai wrote:

thanks to your script, now i can use the internet and set 10 percent of the whole bandwidth for p2p (even with many p2p connections, the combined download speed for p2p is just 38.5kbps).

here's my script:

TCP_BULK="0:"
UDP_BULK="0:"

TCP_PRIO="22 23 53 80 443 1863 5050"

tc class add dev $LAN parent 1:1 classid 1:10 htb rate $(($DOWNLOAD*1/10))kbit ceil ${DOWNLOAD*10/100}kbit burst $D_BURST cburst $D_BURST prio 0
tc class add dev $LAN parent 1:1 classid 1:20 htb rate $(($DOWNLOAD*1/100))kbit ceil $(($DOWNLOAD*5/100))kbit burst $D_BURST cburst $D_BURST prio 1

i've been experimenting with the settings last night (running bittorent while testing the bandwidth speed) and here is my latest setting

tc class add dev $LAN parent 1:1 classid 1:10 htb rate $(($DOWNLOAD*8/10))kbit ceil ${DOWNLOAD}kbit burst $D_BURST cburst $D_BURST prio 0
tc class add dev $LAN parent 1:1 classid 1:20 htb rate $(($DOWNLOAD*2/10))kbit ceil $(($DOWNLOAD*8/100))kbit burst $D_BURST cburst $D_BURST prio 1

i have to set it this way so that the bandwidth speed test result is still around 300kbps and to discourage my room mate to use p2p while were not upgrading to a dsl line. also our there is only one active cellsite in our area (the others are still being fixed due to last storm) and sometimes the bandwidth drops terribly.

thanks for the concern rudy! smile

(Last edited by stevevai on 5 Nov 2006, 01:10)

Is there a way to customize the mark values that the qos script is using?

I am attempting to run both qos-re_1.04 and nocatsplash.  Both of these like to mark
some packets with MARK set 0x4 for quite different purposes and as a result they
seem to be stepping on each other's toes.

Thanks in advance for any help!

--Paul

garageguy wrote:

Is there a way to customize the mark values that the qos script is using?

You will need to modify both the sections that marks the packets, and the part that catches the marked packets. Lines that mark the packets look like:

iptables -t mangle -A mark_chain -m mark --mark 0 -p udp --dport $PORT -j MARK --set-mark 1
iptables -t mangle -A mark_chain -m mark --mark 0 -p udp --dport $PORT -j MARK --set-mark 2
iptables -t mangle -A mark_chain -m mark --mark 0 -p udp --dport $PORT -j MARK --set-mark 4

You'll need to change the number after '--set-mark' (e.g. add 10)

while lines for catching the marked packets look like:

tc filter add dev $QOS_IF parent 1: prio 1 protocol ip handle 1 fw flowid 1:10
tc filter add dev $QOS_IF parent 1: prio 2 protocol ip handle 2 fw flowid 1:20
tc filter add dev $QOS_IF parent 1: prio 3 protocol ip handle 3 fw flowid 1:30
tc filter add dev $QOS_IF parent 1: prio 4 protocol ip handle 4 fw flowid 1:40

Here you need to change the number following 'handle'. Make sure it still matches the number as it was marked. Consistently adding 10 will do the trick.

Finally, you may want the edit the debug section:

[ "$DEBUG" -eq 1 ] && iptables -t mangle -A egress_chain -m mark --mark 1 -j LOG --log-prefix egress_1::
[ "$DEBUG" -eq 1 ] && iptables -t mangle -A egress_chain -m mark --mark 2 -j LOG --log-prefix egress_2::
[ "$DEBUG" -eq 1 ] && iptables -t mangle -A egress_chain -m mark --mark 3 -j LOG --log-prefix egress_3::
[ "$DEBUG" -eq 1 ] && iptables -t mangle -A egress_chain -m mark --mark 4 -j LOG --log-prefix egress_4::

These lines require you to change both the number following '--mark' and following egress_/ingress_. Make sure you don't change the '--mark 0' lines.

Version 1.05 of qos-re is now available. It includes the option to specify a port number or port range along with an IP address.

THANKS!!! :-)
Really -- your work has been great, rudy!

Hi,

I was reading in some QOS furoms, and they swear that incoming bandwidth shaping by IP must be done on local LAN interface (they call it green interface).

In the case of a regular WRT54G in AP mode, i think it is BR0 (bridge between lan and wlan).

What they argue if we do NAT, IMQ & WAN interfaces won't be aware of local IP addressing so mangle rules won't have any effect on marking traffic.

My question is, if set IP_EXPR="192.168.1.23" (my VOIP device), is it going have any effect on incoming bandwidth shaping with your qos-script (hfsc or htb)?

May be you are doing something different, or I really don't know ... just trying to make sense.


Thank you very much for your great work on the scripts. They have been very useful on keeping my pals torrent's from taking over my DSL line smile.

Than you again, and best regards.


Homero Leal

landerx wrote:

I was reading in some QOS furoms, and they swear that incoming bandwidth shaping by IP must be done on local LAN interface (they call it green interface).
What they argue if we do NAT, IMQ & WAN interfaces won't be aware of local IP addressing so mangle rules won't have any effect on marking traffic.

The qos-re script proves these "unidentified sources" wrong wink

landerx wrote:

My question is, if set IP_EXPR="192.168.1.23" (my VOIP device), is it going have any effect on incoming bandwidth shaping with your qos-script (hfsc or htb)?

Absolutely. This is how I use the script, with excellent results. No breakups of the VoIP even with the heaviest downloads.

landerx wrote:

May be you are doing something different, or I really don't know ... just trying to make sense.

What can I say; let me know if it works for you...

That was quick. Thank you for your fast response!!!

VOIP works sometimes, but sometimes it works not.

I'm suspecting my DSL provider has a very variable bandwidth over the time, and this may be the problem.

Sometimes i have 800kbit download, sometimes 720kbit.

Is there any way to have downlaod and upload bandwidth adjusting depending on the actual rate?

I heard about some scipts wich measure ping time, and then do some calculations in order to adjust the bandwidth limits, but haven't tested any of them.

And by the way, I did a "iptables -L -t mangle -v -n" and found this result on the mark chain:

Chain mark_chain (2 references)
pkts bytes target     prot opt in     out     source               destination         
1054K  483M CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x0 CONNMARK restore
  309 19391 MARK       udp  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x0 udp dpt:53 MARK set 0x2
    0     0 MARK       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x0 tcp dpt:22 MARK set 0x2
    0     0 MARK       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x0 tcp dpt:23 MARK set 0x2
    0     0 MARK       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x0 tcp dpt:5900 MARK set 0x2
    1    48 MARK       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x0 tcp dpt:53 MARK set 0x2
   34  1752 MARK       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x0 tcp dpt:9239 MARK set 0x2
116K 9851K MARK       udp  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x0 udp dpts:1024:65535 MARK set 0x4
20554 1016K MARK       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x0 tcp dpts:1024:65535 MARK set 0x4
    0     0 MARK       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x0 tcp dpt:21 MARK set 0x4
    0     0 MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x0 ipp2p v0.8.1_rc1 --ipp2p MARK set 0x4
    0     0 MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x0 LAYER7 l7proto ares MARK set 0x4
6215  321K MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x0 MARK set 0x3
1064K  489M CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0           CONNMARK save 
16821 1022K MARK       icmp --  *      *       0.0.0.0/0            0.0.0.0/0           MARK set 0x1
    0     0 MARK       58   --  *      *       0.0.0.0/0            0.0.0.0/0           MARK set 0x1


According to this, ipp2p and l7proto rules aren't having any effect... right?, since packets and bytes are 0.

Any idea of what could be happening? Most of the time, Ares is the p2p client used in this pc's.

Also, "CONNMARK save" has 1064K packets and 489M bytes wich sounds somekind of strange

If ares is not being detected by ipp2p or l7 filters, then should it be marked by mark 0x03?

May be so many questions for a single post, sorry for that.

Thank you in advance and best regards.


Homero Leal

(Last edited by landerx on 15 Nov 2006, 01:22)

landerx wrote:

I'm suspecting my DSL provider has a very variable bandwidth over the time, and this may be the problem.
Sometimes i have 800kbit download, sometimes 720kbit.
Is there any way to have downlaod and upload bandwidth adjusting depending on the actual rate?

There are some efforts that are geared specifically to wireless connections with variable bit rates. None that I am aware of are mature enough that you want to use them on your OpenWRT router, though.

landerx wrote:

0     0 MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x0 ipp2p v0.8.1_rc1 --ipp2p MARK set 0x4
0     0 MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x0 LAYER7 l7proto ares MARK set 0x4

According to this, ipp2p and l7proto rules aren't having any effect... right?, since packets and bytes are 0.

Any idea of what could be happening? Most of the time, Ares is the p2p client used in this pc's.

I don't think ipp2p and l7proto identify Ares traffic well. You may want to try the --ares option to ipp2p (may require additional modules, I haven't tested this). For l7 the option for Ares is --l7proto ares (again, this will probably require you to load additional modules).
Anyway, if you are using the default port for Ares (UDP port 32285), I'd expect the high port rules to catch the traffic and mark it as bulk. This would explain the high data volume on these rules:

116K 9851K MARK       udp  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x0 udp dpts:1024:65535 MARK set 0x4
20554 1016K MARK       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x0 tcp dpts:1024:65535 MARK set 0x4

Checking /proc/net/ip_conntrack will give you more insight in how connections are marked. You may also want to enable the debug mode, which will log each packet with its marking to logread.

rudy wrote:
garageguy wrote:

Is there a way to customize the mark values that the qos script is using?

You will need to modify both the sections that marks the packets, and the part that catches the marked packets.

Thanks, Rudy, works good now.

Some comments:

1.  To make it easier for 20-qos to work with other things that are using iptables to mark packets,
maybe the mark values could be specified in qos.conf?

2.  Along those lines, qos-stop seems to flush the entire mangle table, not just rules used by qos.
This seems to make it hard for other packet marking apps to play with qos.

3.  Wondering why qos installs under /etc/hotplug.d/iface and not /etc/init.d?  As with the other
comments, I don't really know the issues here, I'm just more used to dealing with init.d scripts to
customize OpenWRT.

Thanks again,

--Paul

garageguy wrote:
rudy wrote:
garageguy wrote:

Is there a way to customize the mark values that the qos script is using?

You will need to modify both the sections that marks the packets, and the part that catches the marked packets.

Thanks, Rudy, works good now.

Great!

garageguy wrote:

1.  To make it easier for 20-qos to work with other things that are using iptables to mark packets,
maybe the mark values could be specified in qos.conf?

I don't think I want to go that way. It seems to me it would needlessly complicate configuration for 99.9% of the users who simply want QoS that is easy to configure and reliable. The remaining 0.1% who want the QoS scripts to work with other iptables applications, will need to deal with all sorts of issues anyway, manually changing the mark values in the script most likely being the least of them wink

garageguy wrote:

2.  Along those lines, qos-stop seems to flush the entire mangle table, not just rules used by qos.
This seems to make it hard for other packet marking apps to play with qos.

Case in point. You will need to make sure all the iptables mangle rules are updated after a qos-stop, reboot or any other event that clears the mangle table.

garageguy wrote:

3.  Wondering why qos installs under /etc/hotplug.d/iface and not /etc/init.d?  As with the other
comments, I don't really know the issues here, I'm just more used to dealing with init.d scripts to
customize OpenWRT.

There has been some discussion on this in this thread (it is getting quite long, I know...). The main reason for 20-qos to be in hotplug is for PPP connections. Only once the PPP connection comes up, do we have our WAN interface available.

Hi.  Thanks for this great QoS script and the support.  I've learned a lot reading this thread. 

I have your latest scripts installed and I think they are set up correctly.  I can see the mark=4 in the conntrack table on my bittorrent traffic and mark=1 on my web traffic.  I have tested my connection speed multiple times and think i have the upload and download speeds set correctly.  Unfortunately, my web browsing is still much worse with bittorrent on.  I would say pages take almost twice as long to load with bittorrent on.  The QoS is definitely helping; without it, the web is unusable while DLing.  I think i have a crappy cable modem connection (RoadRunner, Austin, TX) and the download and upload is very 'bursty' sometimes with a few seconds no bandwidth at all.  Could this be confusing the algorithm?  I know the point of your script is to provide a good web experience without killing download speeds, but I am willing to give up more bittorrent speed for a faster web.  Is there a way to edit the script so that if any priority traffic is detected, all the bulk traffic gets killed for a minute or so?  I would like 90-100% of the bandwidth to go to the web when I am using it and I dont care about DL speed.  It is called "bulk" after all.  I think this would improve things and over the course of 24 hours I dont think my DL speed would suffer much because I am only using the web for a few hours a day.  Any ideas on how to do something like this?  Thanks!!

Martin

trapped in austin:
I'm in Austin too (well, Cear Park), using RoadRunner, and I am successfully running using these scripts.  I have about 30 torrents going on now and am able to browse quite happily.  Here is my qos.conf in case it helps:

DOWNLOAD=4940

UPLOAD=320

L7_BULK=""
L7_PRIO=""
L7_EXPR=""

IPP2P_BULK="ipp2p"
IPP2P_PRIO=""
IPP2P_EXPR=""

TCP_BULK="1024:"
UDP_BULK="1024:"

TCP_PRIO="21 22 80 443 1111 1194 3389 5800 5900"
UDP_PRIO=""

TCP_EXPR="53"
UDP_EXPR="53"

DSCP_BULK=""
DSCP_PRIO=""
DSCP_EXPR=""

IP_BULK=""
IP_PRIO=""
IP_EXPR=""

UDP_LENGTH=256

DEBUG=0

This is pretty much stock except for the port I chose for priority traffic and the bandwidth settings.
The most important thing I think is the UPLOAD setting.  If you set this too high, it doesn't do any useful throttling.  If you set it too low, then you are artificially limiting yourself.  When I chose those settings, I used several bandwidth tests to try and figure out what is best.  Depending on what part of town you're in maybe you could raise that....

(edit)

Oh, forgot to mention -- for me I also have to fiddle with some contrack settings.

edit /etc/sysctl.conf add/change:
  net.ipv4.ip_conntrack_max=2048
  net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=120
  net.ipv4.netfilter.ip_conntrack_udp_timeout_stream=120
  net.ipv4.tcp_westwood=1

If I don't do that, then I'll have things like sporadic timeouts while surfing etc.  This because the table fills up with improperly closed connections from the p2p, and the default timeouts to age them out are something like days.  This makes them minutes.

(Last edited by ziggurat29 on 16 Dec 2006, 15:28)

Sorry, posts 426 to 425 are missing from our archive.