Alchemy Final 1.0 QOS Issues

Discussion in 'Sveasoft Firmware' started by chanchiya, May 15, 2005.

  1. chanchiya

    chanchiya Network Guru Member

    I have been using the Linksys stock firmware and just recently upgraded to Alchemy Final 1.0.

    While I was using the stock firmware, using BitTorrent, I could set the download/upload at 150k/30k and notice no lag (as in possible to play online games). I would set my BitTorrent port to Low priority.

    After loading to Alchemy firmware, I set BitTorrent to be Bulk and am now setting the download/upload limits to 100k/13k and am seeing horrendous ping times (ping is set to Premium) on the order of 150ms to 600ms.

    I have used a bandwidth test and set the QOS download/upload speeds to 70% of reported and am using a cable connection. As this is my first dab at using the firmware, could anyone tell me if they have had similar problems or if I am doing something wrong?
  2. _Shorty

    _Shorty Network Guru Member

  3. chanchiya

    chanchiya Network Guru Member


    I looked into that, Iam using the pre-defined QOS pat files that come with Alchemy and still am running into this problem. The games are given either Express or Premium values and BitTorrent is given Bulk.

    One other question I had was, how do I figure out what value I should put for the upload and download values on the QOS page? I have been using Speakeasy to give me my speeds and scaling the values by 70%. Is this the correct way to do it?

  4. _Shorty

    _Shorty Network Guru Member

    I believe that should work ok, I think the recommended values are 80-90% of your max. I've got mine at 85%. I know the stock bittorrent pattern matches well, so it's probably the games that aren't matching properly. What games are you trying? Only one I've tested with is CS Source, and the stock pattern for CS doesn't match CS or CSS anymore, so you'll get poor results without using the updated pattern.
  5. Lazybones

    Lazybones Network Guru Member

    QOS does not control connections. Make sure you are not hammering your router with too many connections. If you have more than one bittorent client behind your router try and limit the total number of connections to something around 1000 on a WRT54GS, maybe less if you only have the G. The NAT tracking feature that shares your connection consumes memory for every connection made.. When these start to max out you see problems.

    Also setting your QOS up and down lower than required should still let it peak for priority services. That is way its recommended you set these limits lower than your connections possible max, this leaves that little bit of breathing room for when the QOS has run out of allowed bandwidth.

    What are your Ping times without the router in place? 150 is not that bad, 600 is very bad.
  6. pain

    pain Guest


    One thing I picked up on the sveasoft site is to disable the VPN security stuff. Has to do with having another vpn server on the network if you are not using the router as the VPN server. I had the same problem, I tried every fix from rebooting to not changing default admin password, ect, ect, ect. I did that one fix of disable all three options under VPN security and whamo it worked.
  7. chanchiya

    chanchiya Network Guru Member

    I turned off the VPN stuff and it did help my pings quite a bit. Thank you!

    Before I upgraded I was getting average pings of ~35ms while uploaded 30k on Bit Torrent while QOS was enabled on the stock firmware. Now, the average is close to ~130ms while uploading on Bit Torrent at 12k. I can't really unplug my router as I have roommates that are using the Internet connection...

    My current startup script is as follows:

    echo 4096 > /proc/sys/net/ipv4/ip_conntrack_max
    echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
    echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
    echo 512 > /proc/sys/net/ipv4/neigh/default/gc_thresh1
    echo 2048 > /proc/sys/net/ipv4/neigh/default/gc_thresh2
    echo 4096 > /proc/sys/net/ipv4/neigh/default/gc_thresh3
    echo "600 1800 120 60 120 120 10 60 30 120" > /proc/sys/net/ipv4/ip_conntrack_tcp_timeouts

    I am assuming the first line is the max number of connections allowed, what should I set that to?

    I am not sure what the gc_thresh1, gc_thresh2, and gc_thresh3 values do. Could someone explain those to me?

  8. _Shorty

    _Shorty Network Guru Member

    why are you using them if you don't even know what they do?
  9. chanchiya

    chanchiya Network Guru Member

    I am using them because most of what I can find online seems to indicate that those settings are good to use. Unfortunately I don't have much time to spend on routers at home with everything going on...

    My guess is the gc_thresh are garbage collection thresholds for connections, I just wanted to make sure.

    Also, turning off the VPN stuff seems to have fixed all the problems! Thanks for the info everyone!
  10. _Shorty

    _Shorty Network Guru Member

    found this, though I think those defaults refer to something other than Linksys routers, since this was just a man page:

    The minimum number of entries to keep in the ARP cache. The garbage collector will not run if there are fewer than this number of entries in the cache. Defaults to 128.
    The soft maximum number of entries to keep in the ARP cache. The garbage collector will allow the number of entries to exceed this for 5 seconds before collection will be performed. Defaults to 512.
    The hard maximum number of entries to keep in the ARP cache. The garbage collector will always run if there are more than this number of entries in the cache. Defaults to 1024.
  11. _Shorty

    _Shorty Network Guru Member

    well, after a bunch of testing tonight on my WRT54GS I've come to the conclusion that changing the default values of the gc_threshx settings from 128/512/1024 to 512/2048/4096 causes QoS to be much less successful. Generally my DSL line is capable of about 160KB/s downloads. With my QoS settings I seem to be getting about 125KB/s downloads on the gnutella2 P2P network with Shareaza as the client. And with G2 traffic set to bulk and Counter-Strike Source traffic set to premium I seem to have a pretty playable game with the default gc_threshx values. But with the alternate higher values the gameplay goes down the tubes in a much more drastic fashion. While the gc_threshx values may not affect other things in this way, I'd suggest if you're trying to get good gameplay via QoS that you not bother changing the default gc_thresh values. Here are the two setups I tried, with the second one being much more to my liking.

    This went in rc_startup:

    sysctl -w net.ipv4.ip_conntrack_tcp_timeouts="600 1800 120 60 120 120 10 60 30 120"
    echo 512 > /proc/sys/net/ipv4/neigh/default/gc_thresh1
    echo 2048 > /proc/sys/net/ipv4/neigh/default/gc_thresh2
    echo 4096 > /proc/sys/net/ipv4/neigh/default/gc_thresh3
    echo -e cstrike\\n'^\\xff\\xff\\xff\\xff.*cstrikeCounter-Strike' >/tmp/cstrike.pat
    echo -e gnutella2\\n^gnutella.*application/x-gnutella >/tmp/gnutella2.pat

    and the more successful version:

    sysctl -w net.ipv4.ip_conntrack_tcp_timeouts="600 1800 120 60 120 120 10 60 30 120"
    echo -e cstrike\\n'^\\xff\\xff\\xff\\xff.*cstrikeCounter-Strike' >/tmp/cstrike.pat
    echo -e gnutella2\\n^gnutella.*application/x-gnutella >/tmp/gnutella2.pat

    with this in rc_firewall in both cases:

    iptables -t mangle -A POSTROUTING -m layer7 --l7dir /tmp --l7proto cstrike -j MARK --set-mark 10
    iptables -t mangle -A POSTROUTING -m layer7 --l7dir /tmp --l7proto gnutella2 -j MARK --set-mark 40
  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