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 JonEtkins
    How much bandwidth do you actually have? Have you tried lowering your External uplink/downlink bandwidth?

    Have you tried allocating more guaranteed bandwidth to the Premium service?

    When setting my uplink/downlink bandwidth, what I typically do is run a ping to the nearest pingable hop while saturating the uplink or downlink. If ping times jump up when saturating the link, your bandwidth limits are set too high.

    For example, on a T1 (and still running v6) I have to limit bandwidth to 1400 kbits/s to maintain low latency pings when maxing out the connection. This gives up peak performance, but it is required that the Astaro machine be limiting bandwidth and not the router or some upstream device otherwise you have no control over the latency which is what kills VOIP quality.

    Edit: I would also set TOS bits on certain types of traffic.

    For VOIP, DNS, Terminal Apps, Games: Set the TOS bit to minimize delay.
    For BitTorrent, NNTP, FTP: Set the TOS bit to maximize throughput
  • 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.
Reply
  • 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.
Children
  • 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?
  • 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.