Old QOS - not IMQ based

Discussion in 'Tomato Firmware' started by Waester, Apr 30, 2013.

  1. Waester

    Waester Reformed Router Member


    I've been looking around but couldnt find any relevant info about this matter.

    I have been trying to find an up to date tomato version without the imq based qos.

    Reason behind this is that imq based qos seems to use much more CPU then the old qos when downloading (inbound connections) and I have need for QOS only for outbound connections.

    Speed I have:
    TomatoUSB .9054 - 81.2 mbit/s with and without qos
    Toastman .7501.3 - 42 mbit/s with qos. ~80 mbit/s without qos

    The results are from a clean installtion. Only enabling QOS and setting identical classfications and limits on both.

    Limits in Inbound is set to "none" or "no limit" even tried "1% - 100%" or "100% - 100%"

    Should I just stick with .9054 and is it stable enough?

    Or if there is a hero out there that can compile a version of toastman builds without img based qos, as I have no knowledge in that department
  2. Toastman

    Toastman Super Moderator Staff Member Member

    If you find 9054 stable, you could just stick with it.

    Or you could use version 7630 which was considered by many to be a very stable build. The new QOS ingress was added afterwards. It's still a big advance over 9054. Turn off anything you don't need for best throughput, but basically, as 54GL is not suited to these higher speeds.

    No idea of the maximum throughput though :D
  3. Waester

    Waester Reformed Router Member

    Sorry forgot to mention that I have RT-N16.

    I see that 7630 is for K2.4 (WRT54GL)
    Is the K2.6 equivalent "7483.2" for RT-N16?

    And as I use IP Traffic monitor alot should I worry about the existing bug that you and RMerlin fixed in later revisions?

    EDIT: Just looked around your 4shared folder and changelog. Saw that the equivalent of 7630 is 7493 for rt-n16 as 7630 was based on 7493.

    So is 7493 for RT-N16 as stable as 7630 for WRT54GL?
    Or is the 7483.2 recommended for RT-N16?
  4. Toastman

    Toastman Super Moderator Staff Member Member

    Sorry, I should have picked up on the RT-N16.

    I don't remember any particular build :eek: , suffice it to say that I used all builds on a great many RT-N16's in apartment blocks with up to 180 users. That would have included 7493. Genereally speaking, if there was any major problem, I will withdraw the build and delete it on 4shared, so I guess you'll find it is ok.

    7483.2 probably was not much different.
  5. Waester

    Waester Reformed Router Member

    I'm just gonna test it and see for myself which one is better.

    In case I cant find 7493 in the net. Would you have a copy of it left?

    The IPTraffic bug that I was worrying about before. Is it a big problem in these builds?
    By bug I mean the one that RMerlin found and fixed. The one you later incorporated into your builds.

    I think this is the one:
  6. Toastman

    Toastman Super Moderator Staff Member Member

    To be honest, I don't remember experiencing any major problems prior to the fix, and I did use IPTraffic feature a lot. I think it was probably a slow memory leak, without going back to read all the blurb.

    I uploaded what I have into a folder on 4shared. TEST BUILDS / Specials for clients
  7. Porter

    Porter LI Guru Member

    Have a look into /etc/iptables, specifically this line:

    -A PREROUTING -i ppp0 -j IMQ --todev 0
    You can disable it with "iptables -D PREROUTING -i ppp0 -j IMQ --todev 0" I think.

    There are some more lines concerning ppp0 and QoS but I couldn't tell you how disabling those lines would impact your network traffic. Experiment...

    And you could execute this command to disable shaping on ppp0:

    tc qdisc del dev ppp0 root 2>/dev/null
    Waester likes this.
  8. Waester

    Waester Reformed Router Member


    Thanks for the tip!

    Are there anymore commands I can mess or experiment with?

    None the less. That was helpful

    EDIT: While messing around I noticed that there are no "ppp0" interfaces. But looking at the IPTABLES the only ones with IMQ is "br0". Is it the same?
    -A PREROUTING -j IMQ -i br0 --todev 1
    Same with tc qdisc
    qdisc pfifo_fast 0: dev eth0 root bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
    qdisc pfifo_fast 0: dev eth1 root bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
    qdisc htb 1: dev vlan2 root r2q 21 default 50 direct_packets_stat 2
    qdisc sfq 10: dev vlan2 parent 1:10 limit 127p quantum 1518b perturb 10sec 
    qdisc sfq 20: dev vlan2 parent 1:20 limit 127p quantum 1518b perturb 10sec 
    qdisc sfq 30: dev vlan2 parent 1:30 limit 127p quantum 1518b perturb 10sec 
    qdisc sfq 40: dev vlan2 parent 1:40 limit 127p quantum 1518b perturb 10sec 
    qdisc sfq 50: dev vlan2 parent 1:50 limit 127p quantum 1518b perturb 10sec 
    qdisc htb 1: dev br0 root r2q 10 default 0 direct_packets_stat 9102190
    qdisc sfq 10: dev br0 parent 1:10 limit 127p quantum 1514b perturb 10sec 
    qdisc pfifo_fast 0: dev imq0 root bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
    qdisc htb 1: dev imq1 root r2q 10 default 0 direct_packets_stat 7017669
    qdisc sfq 10: dev imq1 parent 1:10 limit 127p quantum 1500b perturb 10sec 
    qdisc htb 1: dev imq2 root r2q 10 default 0 direct_packets_stat 9987047 
    PS: I'm using a toastman build
  9. RMerlin

    RMerlin Network Guru Member

    It's been a while, but if I remember correctly, the leak mostly occurred when you were loading or refreshing the stats page. So if you look at it only once every few days, it could take quite a while before the leak became measurable.

    There was also a potential memory corruption issue however that could cause a segfault - again, it could only be triggered when reloading the stats page.
  10. Waester

    Waester Reformed Router Member

    I got it working!

    Took out my WRT54GL for testing. I noticed that the part with ppp0 is mostly irelevent as different firmware use different interfaces for routing to IMQ. In Toastman 7501.3 for RT-N16 br0 was used and in Toastman 7634 for WRT54GL vlan1 was used

    The iptables command didnt work for me at first but I noticed later in /etc/iptables that the part of the line is in the mangle table so I went and just added "-t mangle" and certainly it worked

    This is done under Toastman 7634 build for WRT54GL (might differ in other firmwares)
    iptables -t mangle -D PREROUTING -i vlan1 -j IMQ --todev 0
    and in tc qdisc at first I thought that im just going to use vlan1 but that resulted Outbound speed limit being removed. So looking in tc qdisc I saw that only 2 interfaces was used for traffic shaping: vlan1 and imq0

    vlan1 = outbound shaping
    imq0 = inbound shaping

    So I went and removed imq0 and it did work. There was no limit in inbound anymore and outbound qos still worked
    tc qdisc del dev imq0 root 2>/dev/null
    NOTE: I actually did it in reverse tc qdisc first then iptables. And I suspect that disabling IMQ in iptables might break bw limiter. Tho I'm not sure. But in my case I dont use bw limiter and disabling IMQ means that traffic didnt need to route thru IMQ. That means less work for the router and more speed for me :)

    This is the inbound speeds I got from the tests using wrt54gl
    QOS disabled: 20 mbit/s
    QOS enabled: 16 mbit/s
    QOS enabled with Inbound shaping disabled: 18 mbit/s
    QOS enabled with Inbound shaping and Inbound IMQ disabled: 19,4 mbit/s

    Thats a big improvement in Inbound speed and I'm positive its possible to disable more QOS routing for Inbound.

    REMEMBER! This is not a tweak or anything to improve QOS inbound speed. I'm actually disabling QOS for Inbound altogether. As I have no need for QOS in Inbound.

    My net is an astonishing wierd 100 mbit/s Inbound and 1 mbit/s outbound -_-

    EDIT: Looking back at the tc qdisc from RT-N16 why was br0 there?

    Correct me if I'm wrong but:

    vlan2: Outbound shaping for QOS
    imq0: Inbound shaping for QOS
    imq1 and imq2: In and Outbound shaping for BWLimiter

    EDIT2: Removing the line -A PREROUTING -i vlan1 -j CONNMARK --restore-mark --mask 0xff
    seems to have yielded another 1-2mbit/s (I'm all for speed) :)
    Bringing me back to full Inbound speed again WITH qos enabled.
    iptables -t mangle -D PREROUTING -i vlan1 -j CONNMARK --restore-mark --mask 0xff
    I dont know what that line does. But its something with Inbound QOS or routing.
    Found an article here about it if someone wants to read:
    Nick G Rhodes and M0g13r like this.
  11. M0g13r

    M0g13r LI Guru Member

    nice !

    it would be nice to have this things as configurable gui
  12. Waester

    Waester Reformed Router Member

    Went and implemented this on my main router, RT-N16, and works perfectly

    Even with QOS enabled I'm getting the full speed that I've mentioned in the first post.

    Now I dont need to stick with the old firmwares :)

    Many thanks to Toastman for your firmwares and especially Porter for the howto on this matter.
  13. Porter

    Porter LI Guru Member

    Please don't remove the connmark-line. While I can't tell you exactly what it does either, it's important for marking packets. Not marking packets the right way will render QoS unusable.
  14. Waester

    Waester Reformed Router Member


    I thought so too at first but then asking around in another forum and letting them look at the /etc/iptables, all of them agreed that removing the Inbound connmark wont affect the QOS as I'm not using it in this case.

    What I should not touch was this connmark line
    -A QOSO -j CONNMARK --restore-mark --mask 0xff
    For now I can't see anything wrong with the QOS, everthing is as it should be. But incase something is wrong then I know where the fault might be.
  15. Nick G Rhodes

    Nick G Rhodes Addicted to LI Member

    Been running this for quite a while, forgot about until I setup my newer router today - gone from a WNR3500L to a E4200 for the better Wifi (50% better throughput in worst room in my house). Works well, thanks.

    With 30MB down and QoS on inbound its very easy to max the CPU out just doing a simple download (1.5 load), alone trying to do any P2P, as its generous bandwidth down I don't need any QoS inbound, but I only have 2MB up, its more important to have good QoS here.
    With the inbound QoS disabled I only get loads of about 0.3-0.4 doing P2P downloads.

    I put the following in the firewall scripts so it runs at startup (using Toastman v1.28.7503):

    tc qdisc del dev imq0 root 2>/dev/null
    iptables -t mangle -D PREROUTING -i vlan2 -j IMQ --todev 0
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice