SpeedMod with tc atm QoS patch for ADSL

Discussion in 'Tomato Firmware' started by hardc0re, Feb 7, 2010.

  1. hardc0re

    hardc0re Network Guru Member

    Hi guys,

    I've ported the tc-atm patch to Tomato and have been using it for a few weeks now. It works wonders for ADSL connections! I would say its a must-have for ADSL QoS.

    Decided to release it as a beta. More info here:

    Unfortunately, this will be only useful for advanced users who write their own QoS scripts, because I did not modify the Tomato GUI. So if you use only the QoS GUI then you won't get the ATM / ADSL calculations. To use the atm mode, you have to use your own QoS scripts.

    NEW "BETA" QoS features in SpeedMod 120

    WARNING: Advanced users only!

    1. Implemented the TC-ATM patch. This enables QoS to work accurately for ADSL users.

    2. Enhanced the SFQ qdisc: Changed the SFQ hash to use Jenkins' lookup3 hash and increased the hash bucket size from 1K to 16K which will result in less collisions.

    3. Turned off HTB hysteresis for more accurate traffic shaping.

    The ATM calculations are not enabled by the QoS GUI in Tomato. You need to manually configure tc using a firewall script. You also need to use the correct overhead amount for your type of ADSL connection.

    TC-ATM details at http://ace-host.stuart.id.au/russell/files/tc/tc-atm/

    Note: I did NOT implement the "nohyst" option in the tc command line because I already disabled HTB hyteresis in the source code.

    I use a WRT54GL v1.1 and PPPoA VC/Mux on a separate ADSL modem, so my overheads are -4 for outbound and 10 for inbound. Other values are given in Russell's website.

    An example line in the tc command for my outbound interface is:

    tc class change dev vlan1 classid 1:10 htb prio 1 rate 800kbit ceil 800kbit overhead -4 atm

    And for inbound IMQ:

    tc class add dev imq0 parent 1:1 classid 1:10 htb prio 1 rate 10000kbit ceil 10000kbit overhead 10 atm
  2. Toastman

    Toastman Super Moderator Staff Member Member

    Very interested in the implications of this but the link you posted was very heavy reading for me, and much of it is over my head. May I ask what kind of improvement you found or expect to see, and what is your opinion as to the desirability of using this mode? (I use PPPOE ADSL2+ 1M/16M Annexe A).

    Do you have any plans to add this into the GUI?

  3. hardc0re

    hardc0re Network Guru Member

    Hi Toastman.

    I think this is a must-have for all DSL users who want QoS to work properly.

    Without this patch, QoS cannot accurately control the bandwidth for ADSL. Why?

    This is because the tc engine calculates the IP bandwidth only, but when the IP packets reach our ADSL modems, they get encapsulated in many smaller ATM packets.

    Unfortunately, ADSL limits the bandwidth based on the ATM line speed, not the IP speed. And the IP speed is not equal to the ATM speed. ATM adds a lot of overhead to the IP packets, and this overhead is highly variable depending on the size of the IP packet (efficiency is anywhere from 89% to a whoppingly low 38%!).

    So sometimes when tc thinks its sending at 100 kbit/sec, it may actually be using 260 kbit/sec of ATM line speed.

    This is why previously to make QoS effective for ADSL users, we had to limit the bandwidth to a value much lower than the actual bandwidth of our ADSL lines, because we never know the actual variable overhead and just take an average value of around 80% which is also not effective all the time.

    With this patch the tc engine will be able to calculate the ATM bandwidth based on the IP bandwidth with almost 100% accuracy. So for example if your ADSL bandwidth is 1 Mbit/s you could really set the QoS to 1 Mbit/s (or maybe very slightly less).

    Unfortunately you really have to:
    (1) know what type of ADSL connection you are using (PPPoA / PPPoE VC-Mux or LLC) to get the right overhead value
    (2) be familiar with the tc commands to use it

    I'm actually not familiar with modifying the Tomato GUI, otherwise I might have done it already. But if time allows, I might give it a go.

    The other missing part of the QoS in Tomato is it doesnt use IMQ for shaping Inbound traffic, which is actually very important. The combination of IMQ and TC ATM patch really makes the QoS extremely effective.
  4. Toastman

    Toastman Super Moderator Staff Member Member

    Thanks for the reply. Sounds like it could be a very useful addition, but it would be nice to have something in the GUI that we can punch in the known connection details, to make it painless.

    Fine about the GUI :biggrin:

    I've been wondering for two years why the Tomato GUI is, to my way of thinking, unfinished. It lacks probably the most important graph (pie) and associated detail that most of us would like to see - an incoming bandwidth per class chart - which would assist greatly in setting up QOS and monitoring applications. Also, the incoming QOS was never finished - the two are tied together. I have often toyed with the idea of duplicating the code for the pie charts to produce a third chart, and just tinkering about, but while I'm sure that this information is pretty much available, the big problem is - I don't have the expertise to do this :(


    We accomplished this early in 2102 - Toastman Tomato now has IMQ ingress, incoming bandwidth pie chart, and per-IP user monitoring ...
  5. occamsrazor

    occamsrazor Network Guru Member

    This is very interesting and thanks for the good explanation. I think I understand. Assuming it works as described I look forward to it being incorporated into other mods, preferably with GUI.
  6. hardc0re

    hardc0re Network Guru Member

    I've been using it personally on 2 different locations with ADSL ISPs, it really works wonders. But to really get useful QoS, Tomato also needs to implement the IMQ (ingress shaping), which it doesn't by default.
  7. occamsrazor

    occamsrazor Network Guru Member

    Just wondering whether there had been any developments on this.... As it stands it sounds great but is a little user-unfriendly for me, I'd need it to be incorporated into the GUI and normal QoS rules (which I do understand isn't a simple task).
  8. Porter

    Porter LI Guru Member

    Unfortunately Russel's site has been hacked it seems, but google cache still has a copy.

    Just now I seem to have figured out my overhead, so I could probably modify my QoS-script.

    Maybe you would like to share a few lines from your script (or a complete one, if you don't mind) to give us an example of a working setup.
  9. Azuse

    Azuse LI Guru Member

    Unless I'm mistaken, it's either install this build or nothing at all? I.e no teddy/victek possibilities? :(
  10. Porter

    Porter LI Guru Member

    Ok, so now I flashed this Tomato build on my Linksys. At first it was rather difficult to find out the overhead my connection requires. Russel's site wasn't that helpful because the tables on the site and the values my modem gave me didn't make sense together. But after reading chapter five (page 48) of this document http://www.adsl-optimizer.dk/thesis/main_final_hyper.pdf I finally found out that a typical ADSL-connection (T-DSL resale) in Germany probably has an overhead of 18 on ppp0.

    One problem remains: I couldn't find out what the overhead for an IMQ-device is, although Russel mentions it, but I somehow didn't get that. Maybe sombody else does. I just use an overhead of 18 for this, too. So far it may result in underuseage, but certainly not in higher pings.

    Just to give you an example on how smoothly my connection now works I attached a screenshot where you can see the connection first without and then with the new QoS-rules.

    Attached Files:

  11. ~nephelim~

    ~nephelim~ LI Guru Member

    While waiting for the patch to be merged in nousb or Vickteck builds
    I looked at http://ace-host.stuart.id.au/russell/files/tc/tc-atm/ to possibly find the optimal MTU value for PPPoE but I was overcome with much confusion after I searched the internet for more informations.

    With a MAX ATM of 1488 the 1472 value was obtained subtracting ATM pad (2) and ATM AAL5 SAR (8) assuming that ethernet overhead should be removed (I'm confused about the reason mentioned)

    Though the suggested value was 1472 (ATM PADDING=YES, ETH=NO, FCS=NO) I found out there are different calculations on the Internet which or might not subtract ATM padding(2 bytes) or FCS (4 bytes) or ETHERNET (14 bytes)

    1488 - ATM AAL5 SAR (8)- ATM pad (2) - PPP(2) - PPPoE(6) - ETH (14) = 1456 MTU

    1488 - ATM AAL5 SAR (8) - PPP(2) - PPPoE(6) - ETH (14) - FCS(4) = 1454 MTU
    1488 - ATM AAL5 SAR (8) - PPP(2) - PPPoE(6) - ETH (14) = 1458 MTU (removing FCS)

    In the end I found conflicting assumptions whenever ATM padding is needed.

    FCS is seemingly ISP dependent but none of the other calculations assume Ethernet overhead can be removed.
    As far I understand Ethernet packets are encapsulated in ATM and are carried between the ADSL modem and the ISP

    In addition confirming whenever FCS is used or not poses another difficulty.

    Can anybody confirm why ATM padding (2byte) is needed, if Ethernet overhead(MTU =1478) should be removed and suggest a way to confirm if FCS is used, please?
  12. occamsrazor

    occamsrazor Network Guru Member

    Any news on this? It sounded good...
  13. mstombs

    mstombs Network Guru Member

    Its all good stuff, but don't expect a major improvement. The big claims seem to compare a connection without upstream QOS to one with optimised calculation. We all know that if you saturate the upload it hits the download, but achievable throughput with lots of small voip or ack packets lower than with bigger ones. Without these patches you need to set the upstream limit lower than with.

    That the kernel patches are now in mainstream means should not be too hard to properly include in tomatousb K26.

    I'm also not too sure what effect the modems have - I know that they also often run a Linux kernel and do chipset specific atm-qos, so can also do buffering and small packet prioritisation etc.

    There's also much technical disagreement on the net on the optimum mtu size. It may optimize the atm link by ensuring a full tcp packet can fit into 31 atm frames, but most of the journey between PC and internet target would be optimized by using a minimum number of maximum size packets, for which there is little disagreement - 1492 for pppoe, 1500 for pppoa. My pppoa ISP recommends 1432, but their own modems default to 1400 - 1500 usually works, but sometimes doesn't - I assume sometimes special routing used with additional encapsulation performed hence the size recommendation.
  14. Porter

    Porter LI Guru Member


    My WRT54GL is running with the and a modified script that utilizes this feature. So far the router has an uptime of 60 days and didn't give me any problems, except finding the right overhead values.
    I came across the problem of finding the right MTU, too, but stopped researching, because the documents where rather difficult to understand, sometimes I had the feeling that they just didn't answer my questions or they even were contradictory. Quite often I had the feeling, that there just wasn't the right documentation, even in the linux mailing lists. I always wanted to write the guy of http://www.adsl-optimizer.dk/ but didn't find the time.

    Btw, that's the script I am using: http://www.linksysinfo.org/forums/showpost.php?p=368239&postcount=14


    With most of us having ADSL-lines managing your scarce upstream is a rather important task.
    First of all you have paid for your bandwidth, so you would like to make use of it as best as possible and secondly there is the safety margin that you always need to deduct from your upstream, because otherwise you can screw up the connection for everyone even if there already is QoS.

    Not using the ATM-Patches on ADSL-lines is making QoS unreliable and inefficient.

    My experience with the patches is that they indeed let me utilize my upstream better. There is no need for big safety margins of around 30% of your line speed, right now I probably only have something of about 7% and I don't even know if this is still neccesary, I just stopped testing. At the same time I was able to maintain the same average ping times throughout the day (I have statistics that go back for around 75 days).

    Unfortunately I wasn't able to find out the right overhead for my IMQ-device (downstream), so I might be wasting bandwidth, but at least the upstream is far from killing my line at any time.
  15. mhook

    mhook Networkin' Nut Member

    I had a quick play around with the tc-atm patch and it does seem to make a difference.

    I am not very familiar with Linux QoS so I set it up first in the GUI and planned to telnet in and modify what was generated in /etc/qos and save that back to flash

    However, I found that you can use "tc class change".
    So I decided to just add a line to the firewall scripts section to alter what the GUI had already set up.

    I'm using PPPoE VC/MUX so my overhead is -4.

    Running repeated speedtest.net and I always seem to get 667kbit/s upload speed with QoS off and no other traffic.
    So I decided to set it to a little less at 650kbit/s as below. I could probably set it higher.
    Honestly, I don't understand how to use the rate calcs in the tc-atm homepage.

    Here is what I added to the firewall script section.
    tc class change dev ppp0 classid 1:10 htb prio 1 rate 650kbit ceil 650kbit overhead -4 atm

    Anyway, before the change, I had to set the max upload rate to 350kbit/s to prevent choppy VOIP calls (around 1/2 the available bandwidth). If I increased it to 650kbit/s and start doing lots of downloads it'd start getting very choppy voip.

    With the tc class change line specified as above I don't get any choppy voice at all and I an almost double upload speed.

    This is a dramatic improvement. I'm not sure whether I've gone about setting this up correctly, but it is an improvement. Any comments on this welcome.
  16. mhook

    mhook Networkin' Nut Member

    I had a more indepth read of the tc-atm homepage and decided my overhead and the rate & ceiling were incorrect.

    I run my draytek vigor 120 modem in bridged mode, but I run PPPoE on my tomato router. The comments

    Well, the last line is not true in my case. The PPPoE Client is running on the Tomato Router. Therefore, I shouldn't be using the 2nd column. I also am guessing that I should be using a PPPoE line rather than PPPoA line based on the comment

    Beware that if your modem is in bridged mode and you are running a PPPoE client on your computer then you need to use a PPPoE row, not the bridged row. So either I am to use the PPPoA or PPPoE line (not confident which one really, the ADSL modem is set to use PPPoA/VCMux but the modem is set to PPPoA to PPPoE full bridge (not half bridge)). I've tested a PPPoE line and used 32 as my overhead rather than the previous -4. Would like some feedback on that, which one would I use?

    Doing the rate calc again I came up with a value of slightly more than 800kbit/s. Well, my modem is showing an upload speed of 800000 which is pretty well spot on.

    So, now my tc line looks like this.
    tc class change dev ppp0 classid 1:10 htb prio 1 rate 800kbit ceil 800kbit overhead 32 atm

    Some basic testing and performance seems around the same as before. The VOIP quality seems fine for listening (download) and upload talking I just rang someone and they said there was absolutely no disturbance in the VOIP quality when I was running speedtest. Previously (or at least prior to me doing anything with the ATM patch) it would be dreadful unless I chopped the bandwidth down to around 350kbit/s in the upload direction.

    By the way, my incoming QoS bandwidth I've set to 99999, i.e. I'm not using it and I'm having no issues there. I'm not sure whether ADSL users should use the incoming QoS or not.

    Comments anyone?
  17. tvlz

    tvlz LI Guru Member

    I've added the TC-ATM patch to Toastman's builds and modified the GUI
    I need somebody to test, I don't use QOS , but have noticed that with the patch everything seems more "responsive"

    In the QOS GUI I added proper ATM Overhead values only if the DSL Modem is in BRIDGED mode
    The way I think it need to be set is to look in the Dsl Modem Gui for WAN MTU (Unless you find what type of Encapsulation your isp uses) and set it to the value > 1500 (mine was under WAN VC Stats, mtu 1540), so I would set 40 as the overhead value

    As for setting the bandwidth I would start with something high (measured - 1%?) to start with, I don't use QOS so I don't know.

    Tvlz's Tomato Builds
  18. tvlz

    tvlz LI Guru Member

    Builds changed per request from Toastman
  19. Porter

    Porter LI Guru Member

    I think it's really great that somebody actually took the time to do this! Thank You!

    I have a few thoughts and questions, though:
    As far as I know these atm-patches are part of the mainline kernel as of version 2.6. So this would mean you only patched K24?

    Why did you limit the overhead calculation to bridge mode? I've never tried the DHCP option (I'm using PPPoE) but I think it isn't any different than doing PPPoE. There still is overhead to be calculated - just less.

    You're right, getting the overhead value is difficult. I just calculated it by hand, using google (for information on my ISP) and looking for hints in the modem GUI. Rusty's page helped and Jesper Dangaard Brouer's master thesis: "Optimization of TCP/IP Traffic Across
    Shared ADSL".

    Please think about uploading your changes to Tomato's git repository. This would be really helpful!
  20. tvlz

    tvlz LI Guru Member

    No I patch k2.6 too, I think it was added in 2.6.25 or some later version, not sure?

    It's was easier it's just a GUI thing, if you have the modem (not in bridge mode) do the PPPoE connection you need to set two values, one ingress one egress.

    Yeah, read those too, that's where I got the info:)

    How is it working out, too soon to tell?
  21. Porter

    Porter LI Guru Member

    That's something I actually never understood. If you are not calculating the overhead in one direction, you never know how much data you are actually sending, right? So why wouldn't you calculate it always? If you don't want to explain this just give me some hints. I'll probably sort it out tomorrow.

    I'm a bit low on backup routers ;), so did you test your K24 build with a WRT54GL?
  22. lefty

    lefty Addicted to LI Member

    Do you guys know if this helps when using vdsl? In the state i live in, DSL is pretty much getting phased out by AT&T, they don't even offer DSL anymore only U-Verse which is a VDSL system.
  23. Porter

    Porter LI Guru Member

    It doesn't look like this is neccessary for VDSL2. Judging by what I've been reading VDSL2 doesn't use ATM-cells any more. It's just "IP over VDSL" or "raw IP".
  24. tvlz

    tvlz LI Guru Member

    In bridged mode the router does calculating of the atm overhead, the same value in both directions.

    If you let the modem make the PPPoE connection it adds the the atm overhead on the way out(egress), so the router needs to know what is & adjust. On the way in(ingress) the modem takes care of the atm overhead but the space was already used.

    Think boxes on a full truck, on it's way in it stops at the first store(modem) & unloads a # boxes(overhead) & reserves space(egress value) on return trip, truck unloads & reloads at the next store(router), fills the truck except for the reserved space(egress value) that the first store(modem) requires.
    That's why you would need to use two values if you let the modem do the work.

    No, don't have one but I added the patches on top of Toastman's k2.4 7633.3 build so it should work fine.

    Found this site it lists common encapsulation settings
  25. M0g13r

    M0g13r LI Guru Member

    can u please make a tomato-K26USB-NVRAM64K-1.28.0500.5MIPSR2Toastman-RT-N-VLAN-VPN-NOCAT.trx build also ?
    without Tomato Anon ?! :)
  26. kthaddock

    kthaddock Network Guru Member

  27. tvlz

    tvlz LI Guru Member

    It's not on till you turn it on if you don't want TomatoAnon don't turn it on!:D

    I need to know if it works first, before I make different builds:)

    KThaddock, it's not the same I added the TC-ATM patches
  28. M0g13r

    M0g13r LI Guru Member

    thx @ kthaddock
  29. kthaddock

    kthaddock Network Guru Member

    Right, I only read without Anon. :rolleyes:
  30. Porter

    Porter LI Guru Member

    Hey tvlz,

    I'm using your new K24 build, but I can't find the overhead setting. I'm using PPPoE.

    Another problem occured: the build is so big that the jffs-partition is unusably small. Could you make a smaller one (I don't necceassarily need VPN or VLAN)? Or what would be even better: could you make a patch of your commit with git? This way I could see how everything works and try to test it myself.
  31. tvlz

    tvlz LI Guru Member

    Forgot to add it:oops:, made a new smaller build with the overhead setting in the gui. Thank for testing
  32. tvlz

    tvlz LI Guru Member

    Found a bug, made a new build 0002.1
  33. Porter

    Porter LI Guru Member

    Seems to be stable so far. Thank you! :)

    I'd suggest one improvement: It's nice of you to provide some default overhead settings, but I think there should be an option to enter a value freely, too.

    Could you make a patch out of your work so that this could be added to the Tomato git? This would be really helpful. Thank you so much again!
  34. tvlz

    tvlz LI Guru Member

    From what I read most ISP's would have used one those default settings so that's why I didn't add a custom field, if you want to you can add it & fix any mistakes too!.;)

    K2.4 TC-ATM patch
    K2.6 TC-ATM patch
  35. cloneman

    cloneman LI Guru Member

    nice thread, finally a solution for ADSL that doesn't involve taking 50% of the upload bits off the table :^)
    I've got a wrt54gl, E4200v2, and netgear 3500l v1.

    Which build should I try? Which router has the least change of bricking, heh

    EDIT: Trying 0002 on my wrt54gl, will report back.
    Is this using toastman as a base? which build?
  36. cloneman

    cloneman LI Guru Member

    man I don't wanna jinx it, but its working so far! This is during my signature crazy stress test (torrents, http, & ftp)

    Build 002 on wrt54gl, internet connection 19/0.8 adsl (Payload rate: 16mbit / 0.680)
  37. cloneman

    cloneman LI Guru Member

    eek, I wrote in a previous post that I have an E4200v2... this is incorrect, I have an e4200v1

    EDIT: Are there builds that secretly already have the TC-ATM patch without the Gui?
  38. Porter

    Porter LI Guru Member

    cloneman: Why would you suspect that? That's definetely not the case.

    Only one exception: if somebody was to upgrade the K26 builds to a more recent 2.6 kernel, then theses builds would have the atm-patches because those patches got into the mainline kernel.
  39. Azuse

    Azuse LI Guru Member

    Nice, very nice - especially for older older routers like my faithful 54gl :)

    I can understand people wanting a manual option, despite isp using fixed standards, there are always oddballs who do things differently e.g. my isp BE (aka O2) use IPoEoATM i.e. LLC Bridged - but finding the info can be a real pain.

    Anyway, this makes a superb difference on a wrt54gl and doesn't appear to require any more cpu either! It does however have me wondering what to qos values should be now. If the default overheads are correct then inputting the actual sync speed will result in 100% bandwidth being available. Fine for the uplink, superb in fact as it finally means I can use it all, but what about the downlink?

    For the moment I've simply set it to the tested value which is resulting in throughput of roughly 90-92%, again improved over the previous 85%, however my uplink/downlink are unbalanced (1150/12000) thus controlling downloads via uploads is impractical are it means loosing 3/4 of my bandwidth.

    With this patch I've had ~500 torrent connections running while streaming video using inbound qos as the primary control without the torrents interfering or producing high pings. Massive improvement! Requires more testing but initial impression is this is the final piece after the imq ingress in making tomatoes qos perform the way people really want it to :)
  40. Toastman

    Toastman Super Moderator Staff Member Member

    Added this to my builds ....

    Thanks to tvlz for the GUI !
    cloneman likes this.
  41. occamsrazor

    occamsrazor Network Guru Member

    Now that this has been enabled in the Shibby build I'm using, a possibly dumb question.... does this have any use for a PPPoE Fiber connection, or is it only for ADSL/DSL ? Thanks
  42. Porter

    Porter LI Guru Member

    It's only for ADSL.
    occamsrazor likes this.
  43. baldursgate

    baldursgate Serious Server Member

    I'm getting less throughput when I enable this setting, and I'm wondering if I did something wrong or if it's the expected behavior. My setup:

    - Toastman build 1.28.0501 (MIPSR2Toastman-RT-N K26 USB Ext 64K NVRAM) on an RT-N66U
    - DSL setting from ISP is RFC1483 Bridged LLC/Snap
    - Link speed 512/3M, speedtest.net says 435/2.65M
    - At the QoS settings page, I enter 425 for max outbound and 2550 for max inbound
    - HTTP download class is set to have 100% max inbound

    When the ATM Encap option is set to None, I get about 2500kbps at speedtest.net. When I set it to RFC1483 Bridged LLC/Snap, I get about 2400kbps (consistently after running multiple tests with the server best for me). Small difference I know, but with my humble connection I'm trying to get all the speed I can get.

    Can anyone help me out?
  44. M_ars

    M_ars Network Guru Member

    Hi everyone,
    i need a little help with that new ADSL setting. I have T-Online (T-Home) with MTU 1492 set in the Tomato-GUI.
    My ADSL-Modem (in Bridge-Mode) has the following settings:

    PVC-Name VPI/VCI Kategorie Protokoll NAT QoS WAN-IP-Adresse MTU Bearbeiten
    br_1_32 1/32 UBR Bridge
    LLC/SNAP * Deaktiviert *

    I use the PPPoE - Connection in the Tomato-GUI and everything is working perfect.

    BUT :) ==> What is the right setting for DSL Overhead Value?

    32-PPPoE VC-Mux OR
    40-PPPoE LLC/Snap OR
    24-RFC2684... Bridged VC-Mux OR
    32-RFC2684... Bridged LLC/Snap

    Thx for your help
  45. Porter

    Porter LI Guru Member

    You don't seem to understand what the ATM feature actually does...
    If you want to use the ATM feature you actually have to enter your line speed minus a few percents and not your measured speed minus ~15%. The ATM feature calculates and therefore deducts the overhead for you!

    The 32-setting works well over here. It doesn't matter which one of the two you choose.
  46. baldursgate

    baldursgate Serious Server Member

    Hmm, if I don't actually get my link speed, but I enter that in the settings, will that cause my line to become congested and QoS to not work? My ISP has its own speed test page, and I only get 2.6M there.

    I was thinking I should enter 3000 in the settings, test, 2900, test, etc. until I see it go below my max, then enter that as my link speed. Would that work?
  47. kyrios

    kyrios Addicted to LI Member

    If I were you, I'll choose 32 since you bridge the modem and let Tomato make the pppoe con.
    I'll choose 40 only if modem does the connection and not in bridged
  48. Porter

    Porter LI Guru Member

    There is always the possibility that your settings are too high. For instance: your modem syncs with different speeds from day to day. A safety margin is always a good idea. If you want to use the ATM feature just don't enter your measured line speeds, since they are too low. Start with 3000, and see whether you get congestion, maybe start uploading and downloading at the same time.

    32 ist the right value for Germany, if you use PPPoE.
  49. CBR900

    CBR900 Network Guru Member

    Is this for VDSL also?
  50. M_ars

    M_ars Network Guru Member

    thx for your answers :)
    So "32" is the way to go in Germany with ADSL, if Tomato does the PPPoE connection and the modem is only in Bridge-Mode.

    If the Modem does the connection including PPPoE then it would be "40" right?

    @CBR900: i think ADSL only
  51. cloneman

    cloneman LI Guru Member

    If you have VDSL, you should be happy that you don't need to turn this patch on. :) (hopefully)
  52. Porter

    Porter LI Guru Member

  53. kyrios

    kyrios Addicted to LI Member


    My modem is D-Link DSL-2640T.
    If not in bridged and modem does make the PPPoE con, the menu is like this:

    The WAN Setting itself has drop-down menu like this:

    When WAN Setting changed into Bridge Mode, the menu will change to this:

    I assume when my modem (DSL-2640T) in Bridge Mode, it only has 2 options:
    24-RFC2684... Bridged VC-Mux
    32-RFC2684... Bridged LLC/Snap

    So I choose 1483 Bridged IP LLC in my D-Link menu and I choose 32-RFC2684 Bridged LLC in Tomato menu.

    I hope you can draw the correct (or wrong?) decision.
    Your modem menu may have richer option then mine?
  54. kyrios

    kyrios Addicted to LI Member

    My ADSL provider has stated clearly the connection they have is PPPoE LLC.
    But I just drawn (stupid) conclusion that my modem do process/convert the upcoming bit/byte/data/... (you name it) from my ISP,
    and output it into 1483 Bridged IP LLC.

    Since my RT-N16 is fed with 1483 Bridged IP LLC from modem,
    So I choose in TC-ATM Patch (in Tomato) 32-RFC2684 Bridged LLC (no need to re-convert back).

    Please remember this is purely stupid conclusion by me.
  55. M_ars

    M_ars Network Guru Member

    thx :) --> not easy
    have to read more about it... i am a little confused the more i read

    Beware that if your modem is in bridged mode and you are running a PPPoE client on your computer (in our case tomato) then you need to use a PPPoE row, not the bridged row.

    So "32" or "40" . Right now i think it should be "40" because my adsl modem says "Bridge
    LLC/SNAP" ? Have to do some testing...
  56. Nelbin Binag

    Nelbin Binag Reformed Router Member

    Hi Guys! Sorry for necro-ing this old post. i just really need some advice:
    - Im from the Philippines
    - Im using an ADSL2+ Line from our local ISP PLDT with a voice phone
    - Im using Zyxel P-660R-D1 Modem
    - Im using Shibby's 1.28 Tomato Latest version as of now
    - My router is an ASUS RT-AC66U
    - Im subscribed at their advertised rate of 10mbps down / 1mbps up
    - Without qos or even router, Straight up plugged computer to modem, I get speedtest net results are 9.7mbps down / 0.7 up
    - Im having trouble configuring my Tomato Shibby QOS settings
    - Here are some screens


    with these settings i only attain something like 7mbps down and .5mbps up from speedtest net. Pretty bad. =/

    Need advice:
    Do i need to change DSL Overhead value? is it better to put it on 32 or should i leave it to none?
    Do i need to put inbound 10,000kbps minus say 15% = 8,500?
    Do i need to put outbound 926kbps minus 15% = 787?
    Do i need to change my MTU?
    Is there other settings should i change?

    Need help with this settings =(
  57. Porter

    Porter LI Guru Member

    1. The overhead value looks correct.

    2./3. I think you overread the term "measured". You need to deduce 15% from 9.7 and 0.7 and enter those values.

    4. I can't tell you whether you should change the MTU. Usually you don't need to.

    What I would like to know:
    Did you change the QoS settings? Those are not the default settings that Toastman is using.
  58. Nelbin Binag

    Nelbin Binag Reformed Router Member

    I did change QOS settings.
    I wanted to start from scratch, so i deleted all qos classification and made a few:

    Default class is Bulk.

    Here is something that confuses me.
    I've changed some settings in conntrack, i really don't feel the difference especially in torrent, does these even help? or should i return it to default settings? the RT-AC66u is a monster, do i have to even reduce timeouts?



    Lastly, just for clarification. Are these correct?
    9.7mbps = multiply .85 = 8245
    0.7mbps = multiply .85 = 595



    Some speedtest results from above settings, pretty sucky =/

    but when i set my DSL Overhead to NONE, i get these results:
    Last edited: Jun 10, 2015
  59. Porter

    Porter LI Guru Member

    There really is no point in deleting all the default filters. It just adds another point of failure since adding your own filters is quite a complex task.

    The default settings on the contrack page are mostly already tweaked. Although I remember lowering the UDP timeouts for my old WRT54GL because uTorrent was still kind of hazardous to my router... You'll have to test those yourself. One user torrenting will probably not cause a lot of harm with your router.

    All I can say is that the defaults have been tested by the users around here and they mostly work.

    Try lowering the safety margin from 15% to 10% or even 5%. A difference of more than 3MBit in your measurements certainly doesn't seem to be correct. Keep in Mind that you WWW class will only let you transfer 60% and after 512KB this connection might end up in the Bulk class (at least judging by your screenshots). Again, I highly recommend sticking with the default QoS-settings.
  60. Nelbin Binag

    Nelbin Binag Reformed Router Member

    Thank you very much Porter. I'll do a reset on my router (Erase all data in NVRAM mem) right now. I'll test 5% safety margin, hopefully it'll run smoothly.

    I'll give an update after maybe 48 hours.
  61. Nelbin Binag

    Nelbin Binag Reformed Router Member

    So far so good, but Youtube videos seem to fall into Crawl (443 UDP Connections) and some other google stuffs (sorry dont have screenies).

    is it safe if i change TCP of both WWW and Xfer to TCP/UDP?
  62. Porter

    Porter LI Guru Member

    Are you using the latest Shibby? As far as I remember Toastman already updated his QoS-rules to handle UDP over port 443 appropriatly. Some other rules are probably missing, too.

    I don't actually know what the side effects of enabling UDP for port 80 and 8080 are. For 443 it pretty much is safe. So in my opinion you could just switch to TCP/UDP and monitor the effects.
  63. Nelbin Binag

    Nelbin Binag Reformed Router Member

    Alrighty then. everything seems to work fine.

    I'm using RT-AC66u Latest Shibby version 128


    and here is what's on my router's about page.


    Just a little information, I'm currently running on a Small Office with 30-50 devices connected to the WIFI everyday. Some people even tend to use torrent... 10MBPS is too damn slow. =/

    Again Thank you PORTER for the advice. Everybody seem to be happy :)

    ### sorry guys for all these screenshots. ###
  64. Porter

    Porter LI Guru Member

    Glad to hear it's working!

    You could either stick with Shibby and hope he updates his QoS-rules with Toastman's or you could use a Toastman build, if there is one. But I don't know if you'd like to go through the hassle of switching firmwares again... Doesn't seem to be really beneficial at this point.

    You're welcome!
  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