Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 19 replies
  • Subscribers 2 subscribers
  • Views 11094 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

QoS tutorial?

JonEtkins
Hi, folks.

I tried replacing my DD-WRT router with my ASG 7.007 box over the weekend, but I had to switch back as I was unable to get the QoS working as I need it.

By way of background, I run a Bittorrent client 24/7, we have Vonage VoIP, we both play World of Warcraft, and I run my own small web and mail server.

With the DD-WRT firmware on my Linksys router, I simply specify my available bandwidth and which services get what level of service, ranging from "premium" to "bulk", and any time there's more traffic than bandwidth, it prioritizes everything seamlessly.  VoIP calls are crystal clear, we never see any latency issues when playing WoW, and BT just sucks up whatever's left over like the good little bottom-feeder that it is. [:)]

Coming from that level of simplicity, I'm having trouble converting to the ASG QoS paradigm where I'm expected to specify how much bandwidth every service should get.  I really don't care how much they get - I just want them prioritized.

Obviously I didn't get it right the first time, as voice quality and game latency were shot to hell unless and until I paused my Bittorrenting.  Can anyone point me to a how-to, tutorial, or set of best practices for QoS?

Thanks!


This thread was automatically locked due to age.
Parents
  • 0
    Can you tell us how you had QoS configured on your ASG compared to your DD-WRT router?
  • 0 in reply to drees
    Can you tell us how you had QoS configured on your ASG compared to your DD-WRT router?
    Sure.  On my DD-WRT, I have the following:



    On the ASG, I have the following:







    Games = WoW,  Mushes = Myriad, and the external interface is down at the moment but was where my ISP cable was connected.

    Thanks for any suggestions.
  • 0 in reply to drees
    Thanks for those suggestions.  I'll likely try it again this weekend, but I have to find a time when the wife isn't gaming!

    I have a 512kbps upstream, and setting the QoS cap at 480 works very well indeed with DD-WRT.  Why would ASG need it specified lower if it's working properly?  I'm running PRTG to keep an eye on the WAN connection, and as you can see it purrs along nicely just below the hard cap:


    I'm also using TestYourVoIP.com to keep an eye on the quality of my VoIP connection - even with BT running constantly, I get scores over 4 most times; between 3.5 and 4 if I'm logged in remotely via RDP as I am now:


    I didn't have either of those tools last weekend when I deployed the ASG; I'll keep an eye on them when I try it again this weekend.  I'll also try allocating more bandwidth to Premium, and tweaking the ToS bits; thanks again.
  • 0 in reply to JonEtkins
    I have a 512kbps upstream, and setting the QoS cap at 480 works very well indeed with DD-WRT.  Why would ASG need it specified lower if it's working properly?

    I'm sure the QoS implementation differs between the 2. Either way, try watching those 2 tools when you deploy the ASG, it should help identify what the issue is.

    I'll also try allocating more bandwidth to Premium, and tweaking the ToS bits; thanks again.

    You might want to try disabling the bandwidth groups altogether as well.
  • 0 in reply to drees
    You might want to try disabling the bandwidth groups altogether as well.
    Forgive my ignorance, but if I disable the groups then how does anything get prioritized?
  • 0 in reply to JonEtkins
    Forgive my ignorance, but if I disable the groups then how does anything get prioritized?

    To clarify, I mean disabling the Interface bandwidth pools. Those just attempt to reserve or limit the bandwidth used by certain ports.

    But I noticed that yours seems to be limited the downstream when it should probably be limiting the upstream. Not sure why that is, on my test v7 machine it always says "(up)" in the Interface selection for bandwidth pools.
  • 0 in reply to drees
    So if I'm reading you correctly, traffic will still be prioritized according to the ranking of the bandwidth pools even if the pools themselves are disabled?  That's the sort of crucial information that's lacking from the manual.

    As to the up/down designation of the interface on the Bandwidth Pools page, I believe it's referring to the up/down state of the interface, not the direction of the traffic.  That had me confused for a while, too.
  • 0 in reply to JonEtkins
    Well, I tried it again last night and it still sucked. [:(]  It limited the outbound traffic just fine, keeping the link at just under the upstream cap, but VoIP was awful, as if there was no prioritization going on at all.  TestYourVoIP.com gave consistent scores of between 1.0 and 1.2.

    I tried upping the reserved bandwidth for Premium, and all the other suggestions above, but nothing seemed to help.

    For now I guess I'll configure ASG in bridge mode, turn off QoS, and run it behind the DD-WRT so that box can handle the QoS.  Kinda sad that a 1GHz/1GB ASG box can't do as good a job at this as a little domestic appliance with a 200MHz processor and 32MB of RAM. [:O]

    Surely I must be missing something?  It's not as if the box was even working hard - the CPU was practically idle while all this was going on.

    Does nobody have a working QoS and VoIP setup that can chime in with some suggested settings?
  • 0 in reply to JonEtkins
    Mine isn't working much better than yours under heavy traffic, but what I do as a workaround is set eMule and Azureus (BitTorrent) to only use 10 or 20kBytes. (I do that within eMule/Azureus's settings).

    This assumes you can control all the machines running the P2P sw.

    FWIW, with eMule & Azureus running full blast, I got a 2.6 and a 1.0 on the VOIP test site. With them throttled to about 30kbytes total, I get between 3.2 and 3.8. With them throttled to about 10kbytes total, I got a 4.2.

    Barry
  • 0 in reply to BarryG
    I'd also recommend you use the speed tests at DSLReports.com or wherever and make sure your upstream bandwidth isn't set higher than the best test result you get.
    I do see you have it at 480 (out of 512).

    I have mine at 460/512 on TimeWarner cable.

    Barry
  • 0 in reply to BarryG
    Mine isn't working much better than yours under heavy traffic, but what I do as a workaround is set eMule and Azureus (BitTorrent) to only use 10 or 20kBytes. (I do that within eMule/Azureus's settings).

    This assumes you can control all the machines running the P2P sw.

    While that would certainly work, I'd much rather make full use of my upstream pipe; I need to maintain my torrent seed/leech ratios as much as possible.

    I'd also recommend you use the speed tests at DSLReports.com or wherever and make sure your upstream bandwidth isn't set higher than the best test result you get.
    I do see you have it at 480 (out of 512).

    I have mine at 460/512 on TimeWarner cable.

    Yep, done that - I regularly see 500+ when I quiesce everything else.  Specifying 480 works just perfectly with the DD-WRT, and even works with ASG as long as there's no prioritization required, it seems. [:(]

    Thanks for the suggestions, though.  I'll probably try lowering the upstream cap, just for the exercise. [:)]
  • 0 in reply to JonEtkins
    So if I'm reading you correctly, traffic will still be prioritized according to the ranking of the bandwidth pools even if the pools themselves are disabled?  That's the sort of crucial information that's lacking from the manual.

    No, but the ToS bits will still be applied which can make a difference in the way packets are delivered.
    As to the up/down designation of the interface on the Bandwidth Pools page, I believe it's referring to the up/down state of the interface, not the direction of the traffic.  That had me confused for a while, too.

    Are you sure? One of the interfaces on my firewall is down now, and it still says "(up)".

    Well, I tried it again last night and it still sucked. [:(]  It limited the outbound traffic just fine, keeping the link at just under the upstream cap, but VoIP was awful, as if there was no prioritization going on at all.  TestYourVoIP.com gave consistent scores of between 1.0 and 1.2.

    Have you tried a simple ping test with and without your torrents running? Pings should stay the same regardless of how much bandwidth is being used.

    I wonder if for some reason your torrent traffic isn't getting picked up appropriately. If you use the firewall to limit traffic to something low, is it restricted appropriately?
Reply
  • 0 in reply to JonEtkins
    So if I'm reading you correctly, traffic will still be prioritized according to the ranking of the bandwidth pools even if the pools themselves are disabled?  That's the sort of crucial information that's lacking from the manual.

    No, but the ToS bits will still be applied which can make a difference in the way packets are delivered.
    As to the up/down designation of the interface on the Bandwidth Pools page, I believe it's referring to the up/down state of the interface, not the direction of the traffic.  That had me confused for a while, too.

    Are you sure? One of the interfaces on my firewall is down now, and it still says "(up)".

    Well, I tried it again last night and it still sucked. [:(]  It limited the outbound traffic just fine, keeping the link at just under the upstream cap, but VoIP was awful, as if there was no prioritization going on at all.  TestYourVoIP.com gave consistent scores of between 1.0 and 1.2.

    Have you tried a simple ping test with and without your torrents running? Pings should stay the same regardless of how much bandwidth is being used.

    I wonder if for some reason your torrent traffic isn't getting picked up appropriately. If you use the firewall to limit traffic to something low, is it restricted appropriately?
Children
  • 0 in reply to drees
    Are you sure? One of the interfaces on my firewall is down now, and it still says "(up)".
    Down as in disconnected, or down as in disabled?  I suspect the former, and that you'll find it changes to (down) if you disable it in Network/Interfaces.

    I wonder if for some reason your torrent traffic isn't getting picked up appropriately. If you use the firewall to limit traffic to something low, is it restricted appropriately?
    I haven't tried setting a low upper limit on that bandwidth pool, but overall the outbound bandwidth on the WAN is being limited to 480kbps per my setting.

    I'll tinker with it some more after the long weekend; thanks for the suggestions.
  • 0 in reply to JonEtkins
    Down as in disconnected, or down as in disabled?  I suspect the former, and that you'll find it changes to (down) if you disable it in Network/Interfaces.

    Ah yes, you're right.
  • 0 in reply to drees

    Have you tried a simple ping test with and without your torrents running? Pings should stay the same regardless of how much bandwidth is being used.


    I've noticed pings get worse with P2P running.

    Barry
  • 0 in reply to BarryG
    I've noticed pings get worse with P2P running.

    Ping should get slightly worse with p2p running, but with QoS set up and working properly should stay close to optimal.

    If ping times go way up as it normally will if you max out your connection without QoS, then no doubt VOIP and any other app which relies on low, stable latency will suffer horribly as well.
  • 0 in reply to drees
    I just switched from ASG 6.x to 7.x and here as well we have QoS issues...

    We have a 5120 / 512 subscription and we use as well bittorrent to "suck" from internet (the best test i guess [;)]

    What we do not understand is why even if we set a bandwidth of 450 kbit/s and assign 128kbit to bittorrent, everything slows down.

    The worst thing, is that when everything slows down, the firewall interface on the public side is not answering anymore!

    I believe that no matter what...the firewall admin interface should ALWAYS be reachable.

    From the manual it is said that:

    "[...] Note that if the available bandwidth becomes temporarily higher than the configured lowest guaranteed value, the firewall can make a projection taking the new bandwidth into account, so that the percentage bandwidth for the priority traffic will be increased as well; [...]"

    So i believe that it should even work if we set an uplink of 200kbit (even having 512) and assign a portion of it to specific services. When more bandwidth is available should increase proportionally....

    So, for the time being...i'm still struggling to have it working... if anyone succeeded please let me know!

    Regards
    Nekos