QOS: prioritize games and throttle downstream speeds for other traffic?

Discussion in 'Tomato Firmware' started by vexingv, Feb 26, 2008.

  1. vexingv

    vexingv LI Guru Member

    i want games such as Counter-Strike and Team Fortress 2 given priority over other types of traffic. i want to accomplish this by throttling the downstream speeds of other protocols such as nntp, torrent, and http downloads. using destination ports for the gaming servers, i have created rules that catch and give gaming traffic "high" priority. i've also created rules to catch nntp, torrent, and other traffic and have been assigned those to lower classes. despite this setup, my games still experience high latencies (150-300ms from 20-30ms normally) if i try to play when there are concurrent downloads.

    when i used ddwrt in the past, there was an "optimize for gaming" option and i noticed that nntp speeds would be throttled; my latency would be 60-70 ms, higher than my usual but not ridiculously high like 300 ms. since using tomato, i've had to manually throttle the speeds (or pause it entirely) in the given downloading application before playing, but i'm now using a new program that does not have any options for adjusting download speeds.

    i think tomato's QOS does work in general as i've seen nntp traffic being throttled to give http downloads greater downstream bandwidth since i have given that more priority than nntp traffic. however, it seems to me (with my rudimentary networking knowledge) that since gaming traffic does not use much bandwidth and the bandwidth received is not as constant as say a download, the downloading application tries to regain and consume whatever bandwidth is available.

    can someone take a look at my settings (attached below) and offer some advice?


    some info: buffalo whr-g54s, tomato 1.16, 1.5M/768 DSL

    Attached Files:

  2. Davka

    Davka LI Guru Member

    Disable "Prioritize ACKs".
    Set Highest to be about 40% - 100% (40% is guaranted bandwidth)

    uTorrent port is an incoming port (and you can't shape incoming traffic). Outgoing source and dest ports are random so you should put all 1024-65535 destination ports (except game ports you catch earlier) to P2p class (B).
  3. vexingv

    vexingv LI Guru Member

    the tomato wiki says that "prioritize ack" should be checked. i have read arguments that state it should be unchecked when using torrents. i should note that i rarely use torrents (and just put it there as an example of some of the traffic). thus, i leave "prioritize ack" checked. most of my downstream traffic is http, http downloads, and nntp. in regards to utorrent, you can actually make it up so that all incoming traffic comes in through one local port and that all outgoing traffic goes to another port, which is exactly what i have done.

    in regards to the outbound limits, the first set of boxes is for creating a minimum guaranteed upstream bandwidth?

    i understand that it is difficult to shape incoming traffic, but it's the incoming traffic that is bogging down my gaming traffic. this is why i have to either pause or throttle nntp manually in the application itself. there is usually very little upstream traffic from my network.
  4. Davka

    Davka LI Guru Member

    You're right about uTorrent. My mistake.

    About incoming traffic shaping: you can't directly control what is coming to you from ISP. When the packet arrives you can only accept it or drop it but it already did take your bandwidth (and dropped packet will be sended to you again in most cases). The only way to control what is coming to you is by outgoing ACK packets. If you send ACKs slower to server then server is sending ie. ZIP file packets slower, too. This is my understanding of this (and that's why you should disable ACK prioritization in first place) :D
  5. vexingv

    vexingv LI Guru Member

    yeah, "prioritize ack" seems to be a confusing issue (whether to leave it on or not). while i still feel that it should be enabled, i experimented with disabling it, loaded some nntp traffic, and started a game. my latency was still very high.

    unless there are any other ideas, i think i've come to the conclusion that tomato simply cannot implement downstream qos like ddwrt can. i still like tomato and have been using it since last july and will stick with it, but i'm curious about how ddwrt manages to implement downstream QOS and whether this can be implemented in tomato. i'm also curious about what exactly is happening when i adjust the download limits in the program itself--ie. how does the program throttle its use of the downstream bandwidth?
  6. Hypernova

    Hypernova LI Guru Member

    They do it by delaying ACK packets mainly.

    TCP as far as I know works like this:

    1) You request a packet.
    2) Server sends you the packet.
    3) You send a small packet to server saying you got the packet and is ready for the next one. <-the ACK packet
    4) Repeat from (2)

    Now you can see that by delaying (3) for a download stream there won't be a new packet sent to you. Effectively slowing the download process.

    This does not work for UDP traffic, UDP is basically (2) until the file is finished so you have no control over the download rate. This is done so that things can get to you ASAP mainly for VOIP and gaming.

    From Wiki:
    "UDP does not guarantee reliability or ordering in the way that TCP does. Datagrams may arrive out of order, appear duplicated, or go missing without notice. Avoiding the overhead of checking whether every packet actually arrived makes UDP faster and more efficient, at least for applications that do not need guaranteed delivery."
  7. vexingv

    vexingv LI Guru Member

    so why is it that Tomato doesn't implement delaying of ACK packets for inbound traffic. also, i just realized/noticed for the first time that the top of the QOS classifications page rules reads "Outbound Direction". thus, all those QOS rules classifications/rules we make are applicable in the outbound direction only.

    will tomato ever implement some type of inbound QOS a la DDWRT?
  8. M_ars

    M_ars Network Guru Member

    there will never be an inbound QoS. DD-WRT can also just control the outgoing traffic. If you wanna have a good ping in games, you will have to slow down the incomming traffic permanently by simply dropping packets. The source will recognize the packetloss (TCP) and will slow down the transfer istantly.
    The Optimize for Gaming option found under the QoS administration(DD-WRT) page enables QoS on some tcp/udp ports found in some games.
  9. Toastman

    Toastman Super Moderator Staff Member Member

    QOS issues

    DD-WRT QOS works in the same way as Tomato on incoming traffic.

    Traffic has either already arrived at your router, or is being queued at the ISP. If it is coming in faster than your router can accept it, then it has to be dropped. [For "proper" QOS to work on incoming traffic it would have to be implemented at your ISP or preferably all the way from the source to your router.]

    So, you must ensure that incoming traffic for your router never begins to build up at the ISP. The incoming QOS is not so sophisticated as the outgoing. So, by using your outgoing QOS you can, for the most part, achieve this. Setting limits low will also limit the amount of incoming data as a result.

    The incoming QOS can also set limits on classes. When the limit is exceeded the packet will be dropped. If it is a TCP packet, then the normal backoff function which is part of TCP will then slow down the connection, which is exactly what we want to happen. But it doesn't happen with UDP. Disabling UDP downloads can fix this.

    The "optimize for gaming" function in DD-WRT enables a whole bunch of L7 filters as I recall, which are very slow and processor intensive.

    You may find greatly improved latency by using "Speedmod" or "Victek" versions of Tomato. Many of my users reported a very big improvement when I first flashed it on the router. Let everybody know if you notice any difference.

    To understand what is happening, try this.

    Don't place any limit on **incoming P2P**. That would only hide what is happening. Then start with your outgoing limit at say 5%, and watch your "realtime" bandwidth chart for a while. Increase in steps of 5%. You will get to a point where the chart begins to flatten out at maximum, with no spikes - and now you can get a feel for the buildup of traffic at the ISP. When your realtime chart starts to approach your maximum download bandwidth, but before it flattens out, that is the time to stop. To do this, you need to set your P2P client to hammer away on dozens of files, turn on DHT and anything else you can find, to try to generate enough incoming traffic, a "worst case" scenario, as it were. (But don't forget to turn off DHT when you've finished).

    In the future, we will add function to the incoming section of Tomato QOS by using IMQ device. This will allow a proper overall bandwidth limit as well as rate and class and individual limits per class (effectively then being the same as the outgoing section). Assuming use of TCP, we will have a much better QOS. UDP hower, is not so controllable.
  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