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

My big wish for DD-WRT... better QoS

Discussion in 'DD-WRT Firmware' started by dscline, Aug 8, 2005.

  1. dscline

    dscline Network Guru Member

    DD-WRT seems to be a great alternative to some of the other firmwares, and I appreciate all the work Brainslayer has put in to it. But everyone has a wish list, and this is mine. :) I think better QoS is what makes many look to alternative firmwares, as many people are starting to use VoIP. I used it on Alchemy for a while, but the big downside I found to it was that it hurt your bandwidth even when the phone wasn't being used. If I lowered the bandwidth settings enough to truly protect my voice traffic under heavy data use, the end result was my overall bandwidth was reduced roughly by the amount of bandwidth VoIP uses. In other words, it was basically just like reserving a certain amount of bandwidth for VoIP, whether VoIP was being used or not. Ideally, it would be a little more dynamic, and only reserve the bandwidth when there was actually a voice connection.

    Anyway, just my small wish. :thumb:
  2. bigjohns

    bigjohns Network Guru Member

    While I agree that there are areas for improvement in the QOS of the router (not just in DD-WRT, though they'll likely happen here first!!), I think you must have set it up wrong.

    Set all PORTS to premium. This allows premium traffic to come from any device so configured.

    Then set your IP phone to PREMIUM by mac address. Any other devices that you want to have unfettered access to the bandwidth you'll set premium too. In my case it is just the IP phone ATA and MY PC. All other devices on the network are not classed by MAC.

    Then set the L7 protocol priorities. I usually set all the standard "internet" stuff (smtp, NNTP, HTTP) to express, any p2p stuff and yahoo / AIM I set to 'bulk'.

    This configuration works great for me. I have 3 Replay TV units that transfer tv shows via the internet. Those units are set to BULK by MAC address because there is no L7 protocol for their traffic. Even with these units MAXING OUT my outbound pipe, when I need the IP phone, the call is perfectly clear after the first second or so.

  3. dscline

    dscline Network Guru Member

    Admittedly, I haven't even tried QoS on DD-WRT. I'm simply asking for better than what HAS been available (and previously, Alchemy was better than stock). I did load the v23 alpha, but I understand that QoS may not be fully working in that version yet, so I haven't even tried it. But I saw the same notes (enter bandwidth values of 80-90% of true bandwidth), so I assumed the same limitation was there. In Alchemy, entering those values at 80-90% of my true bandwidth would limit my bandwidth by 80-90%. NOT entering it that way would result in drop-outs in my conversation during intense uploads.

    If the QoS in DD-WRT has gotten around that limitation, then that's great news! I'll look forward to it being fully implemented in a more final v23. :)
  4. Lazybones

    Lazybones Network Guru Member

    DD_WRT uses the same QoS core code as Alchemy.. The 80-90% values are standard for linux based Quality of service with the packages used.

    As bigjohns stated, if you have service you think are not getting full bandwidth than up them to a higher prioity. Then if you max out your connectuion to the 80-90 values, those services will push past and use a little more space.
  5. dscline

    dscline Network Guru Member

    Hmmm, ok... but if I follow what I THINK you are saying, then the problem is simply inherent to the QoS services we've been using thus far? If that's the case, then my original wish stands: for QoS to become more dynamic, so as to allow full bandwidth on lower priority services when higher priority services don't need it. For me, anyway, this is my list of priorities:

    1. VoIP
    2. Gaming
    3. Everything else
    4. P2P

    Obviously, the only thing that typically would need "full bandwidth" would be "everything else" (except possibly when hosting games with many players). If I understand what you're saying correctly (and I'm not arguing with it, because that agrees with what I've experienced), then to get past the 80-90% figure, I'd have to put "everything else" on a higher priority. But obviously, that defeats the whole purpose of QoS, as I don't want large downloads/uploads to interfere with VoIP or gaming, but I DO want large downloads/uploads to get full bandwidth when those services aren't in use. But as it stands, at least with my experience when using QoS in Alchemy, the 80-90% figures must be used to ensure the priority services are protected from the lower priorities, and those same 80-90% figures are what ends up being my usable bandwidth, at least for the lower priorities.
  6. Lazybones

    Lazybones Network Guru Member

    I don't know of a QoS system that would allow low priority service to have 100% bandwidth. Allowing low priority service 100% would mean that there would be a delay when a high priority service requested bandwidth as it waited for the low prioity service to finish what it started.
  7. bigjohns

    bigjohns Network Guru Member

    The configuration allows BULK (and other queues) to borrow unused bandwidth.

    The configuration as I described my network does exactly that. My Replay TV units can fully saturate the upstream, but when I need my IP phone or my PC (the only other full priority mac address) tries to FTP out, I get what I need.

  8. dscline

    dscline Network Guru Member

    So your Replays can saturate your upload bandwidth, beyond the 80-90% number that you enter for bandwidth? They get the same bandwidth as they would with QoS disabled? Can you even measure that?
  9. Yalla-One

    Yalla-One Network Guru Member

    I couldn't agree more to a QoS wish!

    My Linksys box has 10-15 users in our building, and quite a few of them are *VERY* heavy P2P users. This P2P traffic with so many half-open connections through the Linksys box makes the box crash or the DNS/DHCP function freeze every 24-48 hours.

    I would *REALLY* like to see a feature in dd-wrt that automatically limits this number of half-open connections (and open connections) so that P2P traffic does NO LONGER KILL DD-WRT.

  10. matthiaz

    matthiaz Network Guru Member

    That can be done already! How about lowering the "Maximum Ports" in Administration to someting lower like 1024 or even 512?
  11. zgamer

    zgamer Network Guru Member

    I'd still like to see someway of doing custom l7 hashing for custom code vi the web interface and a classifation tool with it;) granted I'm way over tired and probably dreaming.
  12. Yalla-One

    Yalla-One Network Guru Member

    My impression was that "Maximum Ports" is not equivalent of maximum concurrent sessions both aggregate and on per-IP basis. Furthermore, this has to be set both on established sessions (having completed the TCP three-way hand-shake) and on embryonic sessions (half-open, but still occupying memory). The latter quickly turns into an effective DoS attack

    Can someone please shed some light on this? Thanks!
  13. bigjohns

    bigjohns Network Guru Member

    MRTG says: 48.4 kB/s is my max. This is what the outgoing / upstream bandwidth utilization shows when I have the replay units pumping. I'm on comcast with 4mb down / 384k up.

    My QOS values are set at 450 up / 3000 down.

    Voip works fine when Replay units are pumping.

    I do need to tweek some stuff, because I'm sure my values are not set all quite right, but the replay's work, the Voip works, and my wife does not bitch about web surfing....
  14. dscline

    dscline Network Guru Member

    Then that's great - you're even slightly exceeding you're Comcast cap. :)

    Then this seems to be where the big difference is. Your upload QoS value is set higher than your actual capacity (essentially making that entry irrelevant). If your VoIP traffic is still being protected while your upload is saturated, then this is where my experience with Alchemy differs from yours with DD-WRT. I have 6000/384k with Comcast, and I could reliably get outgoing drop-outs (people on the other end could only hear me intermittantly) when I would do an upload that could reliably saturate my upstream bandwidth, untili I backed my upstream QoS down to around 640 (about 83% of my upload capacity, which is within the rage suggested in the set-up screens for both Alchemy & DD-WRT). Setting this value at 640 results in my available bandwidth being throttled to 640, even when there was no need for the extra 128k by other services. As I mentioned earlier, I haven't tried QoS yet with DD-WRT, but when I saw the same 80-90% suggestion, I assumed the same limitation was there. But if that 80-90% "derate" isn't needed anymore in DD-WRT, that's a change from my experience with Alchemy, and I look forward to trying that with DD-WRT. :)

Share This Page