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

QOS - Script to Limit Download Bandwidth?

Discussion in 'HyperWRT Firmware' started by LiOn, Dec 21, 2005.

  1. LiOn

    LiOn Network Guru Member

    I wonder if someone can help me with QOS - Script to Limit Bandwidth.

    I use ADSL modem and PPPoE to connect. I use Tofu11x in my PC. My connection speed is 384 (arround 40Kbps) download and 128 (arround 12 Kbps) upload speed.

    When I leave Uplink to Auto I got the 102 Kbps in the field. Then I switch to Manual and I enter value of 90 in that field.

    I have 4 wired computers connected to the WRT54G. I don’t use wirelles part of router.

    I enabled QOS and I setup my PC mac adress to priority High, I leave other to low. I also setup my PC port to high priority and other to low... When I tried to play game on Internet I got high latency, while one of other PCs was downloading at full speed from Internet.

    I saw some script to shape bandwidth and I wanted to ask for little help with script.

    I want to limit all other computers exept mine to download speed of 16Kbps.


    Can anyone help me with script please?
     
  2. MarkInDavis

    MarkInDavis Network Guru Member

    I believe QOS settings only affect upload not download.
     
  3. NateHoy

    NateHoy Network Guru Member

    Correct. You, as an ISP user, cannot affect the order in which your ISP sends you packets. Therefore, "inbound QoS" would be meaningless, since the bottleneck is reached before you gain control of the datastream.
     
  4. DallasFlier

    DallasFlier Network Guru Member

    Actually, Nate, that's not at all correct. Let me first excerpt a couple of passages from the latest WRT54G manual:

    Note that it explicitly says "manages information as it is transmitted and received.

    Additionally:

    Note again that it specifically discusses "Incoming Rate Limit" and your ability to set that and throttle to various rates. Another interesting note is about that particular QoS option NOT requiring support from your ISP - implying that other forms are somehow communicating and cooperating with the ISP.

    One of many sites that discuss this cooperation and how it works can be found here:

    http://www.linuxguruz.com/iptables/howto/2.4routing-12.html

    Finally, I haven't tried to understand and digest it, nor have I tested it, but here's a script for limiting inbound traffic, from a user on the HyperWRT forum:

    http://www.hyperwrt.org/forum/viewtopic.php?id=891

    -Gary-
     
  5. NateHoy

    NateHoy Network Guru Member

    OK, I see your point. But I think you're missing what they mean by "port priority" and QoS data coming from the ISP to your LAN. It's not what you think.

    For upload bandwidth, you can control which packets get shoved into the pipe first. So you can easily prioritize this. For download, once they hit your modem (the first time you see them), it's too late - they've already consumed your bandwidth.

    However...

    Quote from the manual: Ethernet Port Priority QoS does not require support from your ISP because the prioritized ports are LAN ports going out to your network.

    Translation: You *can* throttle "download" - from the router to the individual Ethernet ports. That means that the data will be received from the modem into the router and queued in the router, and only sent out on the Ethernet port at the specified speed. I have no idea what would happen on the router if that queue filled up (I suspect it would just start discarding packets like any other router with a backup on its hands).

    Let's say a remote server starts streaming packets to your modem at, say 5mbit, and they were received on the router and directed to a port with a 10kbit downstream limit. I suspect the router would end up throwing away HUGE blocks of bits in short order, but it wouldn't slow down the server sending the data, so you really aren't accomplishing anything except preventing one computer from being overwhelmed, or from wanting to stream video in the first place (training the operator through inadequate bandwidth).

    If your ISP were kind enough to accept some form of "language" prioritizing packets, Ethernet port priority would NOT be the way to do it. The ISP would have to know where on your network the data was intended. If you wanted, say, to use Ethernet port bandwidth clamping, and you had a cooperative ISP, you'd have to have some way to tell your ISP what port you expected to route the data to once you received it, and how much of your bandwidth to use for those packets or which ones are the most important.

    The "pri" flag given in your "Advanced Routing HOWTO" would have been set at the originator of the data, not by you. And it would have to be passed back through every router. So your outbound request would have to contain a "please send back the response with the following priority", and very few Internet routers are going to accept a QoS packet priority from a non-authoritative host. Everyone would be sending EVERYTHING as "Highest" if that was allowed.
     
  6. DallasFlier

    DallasFlier Network Guru Member

    Well yes..... but! You're right, to a point. If a client behind your router is port limited, then if it requests a streaming video, the ISP server & routers are going to start streaming that packet string at video streaming rates, assuming they have the bandwidth on their end to do so. When those packets get to your router, most of them will end up getting dumped on the floor, since the port is limited to a much lower packet rate. And yes, at that point, the ISP server HAS eaten up your bandwidth, despite the fact that the client isn't seeing the streaming video.

    Now, the thing is - that will fairly quickly correct itself. Your client doesn't just say "hey, send me this 50 MB streaming video" and then sit back and receive it all without every saying anything else again. What it actually does is to say "hey, send me the first chunk of this 50MB streaming video" and then when it has received most of that, it says "ok, now send me the next chunk." If most of the first chunk is dropped on the floor, it won't be requesting the next chunk. Easiest way to see this is - start up media player streaming a 50 MB or so file from some site, and then after the first few MB just kill the player, and watch just how quickly the internet activity on your router drops off. Your router isn't going to have to drop that entire 50MB file on the floor.

    Hmm, I actually think you'd be surprised what those routers will be capable of accepting and acting on. Its a pretty safe wager that your ISP is running Cisco commercial grade routers using IoS. Sending EVERYTHING at "Highest" doesn't help you a bit, because IoS is very capable of setting QoS priority on a given stream relative only to OTHER streams to that same IP, and not anything else. Your client (or your router based on QoS) CAN certainly set the PRI bit information, and IoS is very capable of acting appropriately on those requests, without affecting anyone else's connection speeds and priorities. For maybe more info on IoS and QoS than you wanted, go here:

    http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/qos.htm

    So, with or without the cooperation of the ISP, inbound QoS is quite possible. If without that cooperation, then there will be some small lag, as per the example of killing the media player in midstream.

    Now, is the WRT doing this? I can't definitively confirm that, because for me, QoS basically boils down to Vonage vs. me on the computer, and 6Mb is more than I'm generally using. Can you refer me to where Thibor said that the WRT isn't doing inbound QoS? Would like to read that, particularly in light of Linksys' claims to the contrary in the latest WRT manual.

    -Gary-
     
  7. NateHoy

    NateHoy Network Guru Member

    Yes, that does work, though there are plenty of streaming apps (multicast) that do not expect such acknowledgments. Vonage is one of them, actually.

    But that is application-dependent, and though I know I'm splitting hairs when I say this, that is not QoS. It's part of the TCP stack, not the IP stack. UDP does not have it.

    So, yes, for TCP-based applications (not for Vonage, not for games, and not for any UDP streams), you are correct. The lack of acknowledgment of the last packet forms sort of a "poor man's QoS", by "training" the remote to not send any more packets by not acknowledging what you have so far (damned kids! They never call, they never write...) LOL.

    How does my client set a PRI flag on a packet it doesn't have? I'd have to set up a filter on the Cisco IOS router that sets the flag based on some criteria from the routing table of my WRT54G. That means I'd have to upload my routing table with PRI values continuously, every time I made an outbound request to another server, so the Cisco can "simulate" all of my routing then sets a PRI flag based on what it predicts my WRT54G would do. Either that, or I'd put a "requested PRI for the response(s) to this packet" on every outbound request and the Cisco maintains its own PRI table for me.

    First, there are no claims to the contrary. The router can do throttling (primitive QoS) to its Ethernet ports. That's pretty much what the manual is saying. Packets outbound from your PC are given QoS when they hit your modem from the router, and packets inbound to your PC can be given QoS (to an extent) when they hit your network. But your router can no more control packets coming to the WAN port than it can tell your PC what order to enqueue packets on its internal LAN card. QoS is, by nature, outbound from a device only.

    As to the discussion:

    http://www.linksysinfo.org/modules....opic&t=11247&postdays=0&postorder=asc&start=0
     
  8. DallasFlier

    DallasFlier Network Guru Member

    Hmm, well, ok - yes, I'd agree that that's splitting hairs a bit. If the end result is the same - or close - then its "good enough" QoS, particularly for a $50 router. Is there a definition somewhere that says QoS must be at the IP layer, or are you just noting that at the next layer above not all apps will be "throttled" with the same efficiency?

    Yes, TCP wants that "ack" packet by packet, so those streams will shut off VERY quickly. Even the UDP ones though, will shut down "relatively" quickly, at least in human timeframes vs. computer timeframes. If I unplug my Vonage adapter in the middle of a call, how long do you think the inbound datastream from the Vonage server will continue? Not very long, I'm guessing - there's obviously some "handshaking" going on somewhere further up the stack at the application layer, I believe. So if primitive throttling can throttle a TCP app almost instantaneously, and a UDP app at least within only a handful of seconds, that's still not bad, especially for our little $50 routers. It sure ain't what you'll get on a $2000 Cisco, but then we really don't need that.

    Yes, I think it IS possible to set those bits on outbound requests, and let the Cisco maintain a PRI table for the (few) apps and streams that you're doing at any one time.

    Well, there's no hard & fast proofs, but as far as "claims to the contrary", why would Linksys put the statement into the manual that says "Ethernet Port Priority QoS does not require support from your ISP because the prioritized ports are LAN ports going out to your network," unless some of the OTHER QoS methods offered *do* require support and cooperation from the ISP - that the device the manual is written for is supporting? Again, I have no proof that the lowly WRT is really doing this, but it DOES seem kind of interesting that they put that little statement into the manual.

    At any rate - interesting discussion!

    -Gary-
     
  9. robsonn

    robsonn Network Guru Member

    Hi I'm new on this forum. I can help you :D I createad my own script. He can limit download speed and upload speed. I use HTB + iptables to mark packets. Script has little diferences from normal PC beacuse WRT54G have very specific hardware construction (marking LAN & WAN as the same interface eth0 .. and others).
    I have WRT54G v2.2 + HyperWRT Tofu 11 and this script works excelent.
    Using this script i use Tofu QoS too beacuse its prioritizing packets, and limits hole upload. And my script shape traffic not QoS him :D.

    Little description:
    One default class 1:10 - users ip that packets arent marked (nt listed in script) are joined to default class in case of my script they have max. down / upload
    class 1:10-19 - users download classes rate = guaranteed, ceil - max speed allowed
    class 1:20-2x - upload classes rate, ceil same as above

    @EDIT - I CHANGED VALUES IN SCRIPT TO MEET YOUR NEEDS. YOU ONLY MUST CHANGE IPS. IN FIREWALL SCRIPT AT THE END. DON TOUCH REST :D or if you know what you are doing :):):)

    your download 320 kbps guaranteed, 384 max :D
    your upload max :D or max in tofu qos settings

    rest of users downlad 32 kbps guaranteed 64 max
    rest of users upload 8 kbps max 16 kbps

    most important as usual is not download speed but upload speed. When you upload to much data you create queue in your modem and at your ISP router and this affects your pings and download speed and hole rest...

    #------------------------------------------
    #put this in startup script
    #------------------------------------------
    #WRT54G v2.2
    #eth0 = LAN & WAN, eth1 = WLAN
    #start of the script
    #script by ROBSON

    #this delete all htb rules on eth0
    tc qdisc del dev eth0
    iptables -t mangle -F
    iptables -t mangle -X

    #this create a htb queue on eth0, the class 10 will be the defaut class
    #id of the queue is 1:
    tc qdisc add dev eth0 root handle 1: htb default 10

    #this create the main class 1:1
    tc class add dev eth0 parent 1: classid 1:1 htb rate 384kbit burst 6k prio 0

    #now this create one secondary class per user
    # with rate=min and ceil=max
    #------------------------------------------ users download classes
    #you :)
    tc class add dev eth0 parent 1:1 classid 1:10 htb rate 320kbit ceil 384kbit burst 6k prio 0
    #rest of ppl on net
    tc class add dev eth0 parent 1:1 classid 1:11 htb rate 32kbit ceil 64kbit burst 6k prio 2
    tc class add dev eth0 parent 1:1 classid 1:12 htb rate 32kbit ceil 64kbit burst 6k prio 2
    tc class add dev eth0 parent 1:1 classid 1:13 htb rate 32kbit ceil 64kbit burst 6k prio 2
    #------------------------------------------ users upload classes
    tc class add dev eth0 parent 1:1 classid 1:21 htb rate 8kbit ceil 16kbit burst 6k prio 2
    tc class add dev eth0 parent 1:1 classid 1:22 htb rate 8kbit ceil 16kbit burst 6k prio 2
    tc class add dev eth0 parent 1:1 classid 1:23 htb rate 8kbit ceil 16kbit burst 6k prio 2

    #we use SFQ strategy on each class
    #download classes
    tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10
    tc qdisc add dev eth0 parent 1:11 handle 11: sfq perturb 10
    tc qdisc add dev eth0 parent 1:12 handle 12: sfq perturb 10
    tc qdisc add dev eth0 parent 1:13 handle 13: sfq perturb 10
    #upload classes
    tc qdisc add dev eth0 parent 1:21 handle 21: sfq perturb 10
    tc qdisc add dev eth0 parent 1:22 handle 22: sfq perturb 10
    tc qdisc add dev eth0 parent 1:23 handle 23: sfq perturb 10

    #now we associate each class with a filter via fmark
    #excepted class 10 wich is the default class
    #download classes
    tc filter add dev eth0 parent 1:0 prio 2 protocol ip handle 11 fw flowid 1:11
    tc filter add dev eth0 parent 1:0 prio 2 protocol ip handle 12 fw flowid 1:12
    tc filter add dev eth0 parent 1:0 prio 2 protocol ip handle 13 fw flowid 1:13
    #upload classes
    tc filter add dev eth0 parent 1:0 prio 2 protocol ip handle 21 fw flowid 1:21
    tc filter add dev eth0 parent 1:0 prio 2 protocol ip handle 22 fw flowid 1:22
    tc filter add dev eth0 parent 1:0 prio 2 protocol ip handle 23 fw flowid 1:23

    #-------------------------------------------
    #put this part in firewall script
    #-------------------------------------------

    #BE AWARE - ONLY THING YOU MUST CHANGE IS USER IP'S. THEY
    #MUST HAVE STATIC ASSIGNED IP'S via DHCP
    #or with DHCP off
    #DONT LIST YOUR IP - if you do you will be limited :D
    #after saving scripts reboot router and voila
    #where in dowload and upload is eg. 192.168.1.11 put in
    #these 2 places the same ip eg. 192.168.1.99

    #marking DOWNLOAD packets
    #you must add every ip that you want to shape his traffic
    #set mark indicate HANDLES from above script
    iptables -t mangle -A POSTROUTING -d 192.168.1.11 -j MARK --set-mark 11
    iptables -t mangle -A POSTROUTING -d 192.168.1.12 -j MARK --set-mark 12
    iptables -t mangle -A POSTROUTING -d 192.168.1.13 -j MARK --set-mark 13

    #marking UPLOAD packets
    iptables -t mangle -A FORWARD -s 192.168.1.11 -j MARK --set-mark 21
    iptables -t mangle -A FORWARD -s 192.168.1.12 -j MARK --set-mark 22
    iptables -t mangle -A FORWARD -s 192.168.1.13 -j MARK --set-mark 23

    #end of the script

    greets
    Robson
     
  10. Thibor

    Thibor Super Moderator Staff Member Member

    @robsonn: eth0? the wan device for most wrt's is vlan1(it was eth2 for wrt54gv1 if i recall correctly), or ppp0 in the case of pppoe connection. I think eth0 is the device for the entire 5 port switch, and would also, i assume, affect lan based traffic over the entire device
     
  11. robsonn

    robsonn Network Guru Member

    In my WRT54G v2.2 only eth0 works properly. Yes its truth that in case of PPPoE you should use ppp0 but Lion use modem as bridge and WRT works in DHCP mode.
    I tested this script on every interface, in WRT54G v2.2 they are:
    eth0 - WAN & LAN (vlan1 - WAN, vlan0 - LAN)
    eth1 - WLAN
    The cpu port is seen by Linux as eth0.
    In my case LAN speed aren't affected beacuse i mark packets that come from WAN (download) and leave LAN to WAN (not LAN to LAN). Correct me if i'm wrong but packets traveling only in lan shouldn't be routed.
    And about vlan0 and vlan1 it looks like in v2.2 only cpu has access to packets in this interfaces. I made few scripts in different ways (ip tables, u32 mark ..) and i cant get this scripts to work with other interface than eth0.
     
  12. dtswk

    dtswk Network Guru Member

    Thanks Robsonn, tried the script, but doesn't seem to be working for me... Would really appreciate any advice. I'm running it on a WRT54GSv4 with Thibors 11 + Wol firmware.

    I'm really only concerned with upload and i've limited one of my boxes which is still uploading at 50Kbs...

    Here is the exact script i'm using incase i've made a boo boo.. My link is 2Mb down and 512Kb up.

    #------------------------------------------
    #put this in startup script
    #------------------------------------------
    #WRT54G v2.2
    #eth0 = LAN & WAN, eth1 = WLAN
    #start of the script
    #script by ROBSON

    #this delete all htb rules on eth0
    tc qdisc del dev eth0
    iptables -t mangle -F
    iptables -t mangle -X

    #this create a htb queue on eth0, the class 10 will be the defaut class
    #id of the queue is 1:
    tc qdisc add dev eth0 root handle 1: htb default 10

    #this create the main class 1:1
    tc class add dev eth0 parent 1: classid 1:1 htb rate 2000kbit burst 6k prio 0

    #now this create one secondary class per user
    # with rate=min and ceil=max
    #------------------------------------------ users download classes
    #you
    tc class add dev eth0 parent 1:1 classid 1:10 htb rate 1800kbit ceil 2000kbit burst 6k prio 0
    #rest of ppl on net
    tc class add dev eth0 parent 1:1 classid 1:11 htb rate 600kbit ceil 1000kbit burst 6k prio 2
    tc class add dev eth0 parent 1:1 classid 1:12 htb rate 600kbit ceil 1000kbit burst 6k prio 2
    tc class add dev eth0 parent 1:1 classid 1:13 htb rate 600kbit ceil 1000kbit burst 6k prio 2

    #------------------------------------------ users upload classes
    tc class add dev eth0 parent 1:1 classid 1:21 htb rate 100kbit ceil 200kbit burst 6k prio 2
    tc class add dev eth0 parent 1:1 classid 1:22 htb rate 100kbit ceil 200kbit burst 6k prio 2
    tc class add dev eth0 parent 1:1 classid 1:23 htb rate 100kbit ceil 200kbit burst 6k prio 2

    #we use SFQ strategy on each class
    #download classes
    tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10
    tc qdisc add dev eth0 parent 1:11 handle 11: sfq perturb 10
    tc qdisc add dev eth0 parent 1:12 handle 12: sfq perturb 10
    tc qdisc add dev eth0 parent 1:13 handle 13: sfq perturb 10
    #upload classes
    tc qdisc add dev eth0 parent 1:21 handle 21: sfq perturb 10
    tc qdisc add dev eth0 parent 1:22 handle 22: sfq perturb 10
    tc qdisc add dev eth0 parent 1:23 handle 23: sfq perturb 10

    #now we associate each class with a filter via fmark
    #excepted class 10 wich is the default class
    #download classes
    tc filter add dev eth0 parent 1:0 prio 2 protocol ip handle 11 fw flowid 1:11
    tc filter add dev eth0 parent 1:0 prio 2 protocol ip handle 12 fw flowid 1:12
    tc filter add dev eth0 parent 1:0 prio 2 protocol ip handle 13 fw flowid 1:13
    #upload classes
    tc filter add dev eth0 parent 1:0 prio 2 protocol ip handle 21 fw flowid 1:21
    tc filter add dev eth0 parent 1:0 prio 2 protocol ip handle 22 fw flowid 1:22
    tc filter add dev eth0 parent 1:0 prio 2 protocol ip handle 23 fw flowid 1:23


    #This is my SNMP script, works way better than the default SNMP demon
    sleep 5
    wget -P /tmp http://10.1.1.201/snmpd
    wget -P /tmp http://10.1.1.201/snmpd.conf
    cd /tmp
    chmod +x ./snmpd
    ./snmpd -c /tmp/snmpd.conf





    #-------------------------------------------
    #put this part in firewall script
    #-------------------------------------------

    #BE AWARE - ONLY THING YOU MUST CHANGE IS USER IP'S. THEY
    #MUST HAVE STATIC ASSIGNED IP'S via DHCP
    #or with DHCP off
    #DONT LIST YOUR IP - if you do you will be limited
    #after saving scripts reboot router and voila
    #where in dowload and upload is eg. 192.168.1.11 put in
    #these 2 places the same ip eg. 192.168.1.99

    #marking DOWNLOAD packets
    #you must add every ip that you want to shape his traffic
    #set mark indicate HANDLES from above script
    iptables -t mangle -A POSTROUTING -d 10.1.1.201 -j MARK --set-mark 11
    #iptables -t mangle -A POSTROUTING -d 10.1.1.220 -j MARK --set-mark 12
    #iptables -t mangle -A POSTROUTING -d 192.168.1.13 -j MARK --set-mark 13

    #marking UPLOAD packets
    iptables -t mangle -A FORWARD -s 10.1.1.201 -j MARK --set-mark 21
    #iptables -t mangle -A FORWARD -s 10.1.1.220 -j MARK --set-mark 22
    #iptables -t mangle -A FORWARD -s 192.168.1.13 -j MARK --set-mark 23

    #end of the script
     
  13. koprataat

    koprataat Network Guru Member

    same here. I can't get robsonn script working with GSv4 (Thibor11 firmware). Any ideas?
     
  14. jonahj

    jonahj Network Guru Member

    I also had problems running my own QoS/Shaping scripts when I entered then in the startup and firewall section. What I found was that the scripts are created but not ran at bootup. To get around this problem, I had to telnet into the linksys and manually executed them. Once this was done, everything worked great. To test whether your scripts are running type: tc -s -d class show (your interface).

    BTW, I have 4 PCs and a Vonage phone on my home LAN. Two of the PC's are constantly running Bitturrent while the other two are being used for other purposes. I can use my Vonage phone without interference AND since I created an "Express Lane" for the interactive, all PCs can browse the Internet without lag.

    I'm also shaping and applying QoS on inbound and outbound traffic.
     
  15. robsonn

    robsonn Network Guru Member

    Maybe try different interfaces. Instead of eth0 use vlan1 or vlan0 (change this in all places where eth0 occurs, save script and reboot). Theoreticly WRT54G and WRT54GS are having same hardware except Speedbooster. But i dont know how Thibor's firmware handles scripts. Maybe Thibor will say few words about this.
     
  16. Thibor

    Thibor Super Moderator Staff Member Member

    it(GS) handles scripts in EXACTLY the same way as tofu's, but i'll try the script tomorrow and report back
     

Share This Page