router slowdown problem

Discussion in 'Tomato Firmware' started by master89x, Aug 28, 2009.

  1. master89x

    master89x Addicted to LI Member

    Hi! I'm a WRT54GL v1.1 user flashed with Tomato 1.25 firmware. However I've been experiencing huge problems with P2P applications. As soon as I launch Limewire, the router slows down immediately and therefore I have trouble accessing the Setup GUI through its default address
    Is there any solution for this problem? How about tweaking the QoS?

  2. Toastman

    Toastman Super Moderator Staff Member Member

    You should be able to find something to help here:

    Read thought the thread to get an idea of what QOS can do.

    Then, I would recommend using the complete QOS setup example near the end of the thread, and after you have it working, tweak it to suit your own use.
  3. master89x

    master89x Addicted to LI Member

    Thanks... It's kinda strange why I can't access the Setup GUI while Limewire is running. Everything slows down. It might be a firewall problem or something. I've checked the settings and there is no filter to P2P connections enabled.
  4. Planiwa

    Planiwa Network Guru Member

  5. Toastman

    Toastman Super Moderator Staff Member Member

    Planiwa's article is very pertinent. Check it out!

    Planiwa - I've been experimenting just for interest's sake. I set a script in scheduler to drop idle connections every 3 minutes. While this seems to have no significant effect on any applications as far as I can ascertain, it has made a big difference at one or two sites which crashed regularly. Can you assist? I'd like to run that script to drop idle connections when certain conditions occur - perhaps when conntrack reports more than "n" connections - run the script. It seems to need several seconds seconds or so before running, perhaps to calculate which connections are currently idle. I think this might make some difference to the stability under load, even with a delay of 8-10 seconds. And perhaps it is possible to reduce or eliminate this delay? Any ideas on this?

    The script is: echo "10" > /proc/net/expire_early
  6. Planiwa

    Planiwa Network Guru Member

    I would not use "expire_early" except to avoid rebooting, since the effect it has on users is almost as drastic as rebooting. It is a very crude measure which is (almost) completely unnecessary. It will make serious users very angry, because it destroys their very well-behaved long-running sessions. It is no mistake that the Unix default timeout for established TCP sessions is 5 days.

    It works by setting the idle time of all connections 10 seconds short of the respective timeout. The result is that all connections that do not become active in the next 10 seconds will be timed out.

    This is the opposite of what you need to do in a Connection Storm, where too many connection attempts become active too fast, causing a sharp spike. It is those thousands of reckless short-lived connection attempts that are the problem, not the handful of extremely well-behaved long-lasting and mostly quiescent sessions.

    If the Timeout settings that I recommend in the DSLR article are not suffiecient, I would suggest reducing the 20s values down to 10s.

    Rather than running "10s expire" whenever, I would simply time out the questionable connections in 10s. That amounts to running "10s expire" continually, but only on the suspect ones.

    Counting connections can be tricky. Almost everything on the net about connection counting in 2.4 is completely wrong. The trick is to only use cat on proc files, or else you miss exactly half the entries -- you end up thinking there are 1000 connections when there are 2000.

    I have some nice tools for monitoring connections. And a connection viewer.

    And a Watcher that checks every 7 seconds and sends me a voice alert when there are too many connections, and also makes a copy of the conntrack table so I can view it and analyse it.

    But I've found that although iptables connlimits are of limited use, keeping the volatile timeouts really low -- 10s to 20s, keeps connection storms under control.

    I can see them start rising, but before they get too high, the bottom times out from under the spike.

    Let me know if I can help with anything specific.

    I also have a very handy "idle" command that reports on how many connections have been idle for 0,1,2, 3, 4+ seconds ...
  7. Toastman

    Toastman Super Moderator Staff Member Member

    Understood, makes sense. And thanks for confirming how that command works. However, I'm not seeing longterm connections timed out by this command, large downloads via http or messenger sessions all stay connected (which isn't actually what I'd expected). After checking that for a week, I tried it on remote sites with some positive results. But I agree, some better strategy is needed. How to time out these questionable connections?

    I also use the (very) short volatile timeouts here, but routers do still reboot. I cannot usually say with 100% certainty if those particular cases are due to connection storms, as they are remote sites, and I don't get much information from them, but the script did help.

    Your diagnostics sound very useful. Might be very educational! Thanks!
  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