1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

solved! Slowdown/disconnect (was: VNC keeps disconnecting)

Discussion in 'HyperWRT Firmware' started by e1e0n, Mar 30, 2006.

  1. e1e0n

    e1e0n LI Guru Member

    :cry:

    I have WRT54GL with latest Thibor 14 build.
    Works much more stable then DD-WRT, but VNC connection from internet very unstable (terminates very-very often, sometimes after few seconds). It used to work good before I connected through router. Other things work good though.
    Any ideas?

    Thank you,
    Leo

    PS Actually no, the problem exists with other things also, some time after slowdown/disconnecting problem appears, router doesn't see my computer anymore. I am not at home now, so don't know that is the problem :(.
    I am using eMule and mTorrent at the same time, but I set them to very low settings (like not more then 50 connections). Set max connections to 8192 (max) and connection life 600 sec (min).
    What should I do more?

    PPS

    Rebooted router, no effect.... Looks like mine computer wasn't able to reestablish connection to router. :sad:
     
  2. Thibor

    Thibor Super Moderator Staff Member Member

    i've not really got any idea why your connection is unstable. you could try reducing your MTU value to 1400, or try turning on QoS as you have stated that you're using P2P software. also you shouldn't need 8192 connections, each bucket uses 384 bytes if i recall correctly. i use bittorrent 24/7 and i've set mine to 600/2048 and that is plenty for me.
     
  3. e1e0n

    e1e0n LI Guru Member

    Thank you Thibor!

    Actually I found some useful info on configuring router and finally it works stable (so far), no performance or stability issues! :thumbup:

    This helpd me (or maybe both this and QoS):

    echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
    echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
    echo "600 1800 120 60 120 120 10 60 30 120" > /proc/sys/net/ipv4/ip_conntrack_tcp_timeouts

    Just wonder what do these magic numbers mean (in last line)?
    And what else would you suggest for me?

    Thank you!
    Leo
     
  4. NateHoy

    NateHoy Network Guru Member

    echo "600 1800 120 60 120 120 10 60 30 120" > /proc/sys/net/ipv4/ip_conntrack_tcp_timeouts

    This line defines the tineout intervals for various types of connections. The most significant number for most P2P users is the second number (1800 in your example). That number defines the number of seconds it takes for an active connection that has no activity on it to be turned into an "IDLE" and therefore reuseable connection.

    The "other" significant entry is the number of connections that are tracked in the connections table (ip_conntrack_max if I recall). Thibor uses 2,048 - I generally say that a MAXIMUM value of 4,096 would be an ideal, much beyond that and you are consuming a lot of memory to little good purpose, unless your needs are very "out there".

    Both numbers can easily be changed in the GUI, there is no need for your startup script to accomplish the task. However, as you have seen, your startup script (which is the equivalent of putting "1800" in the tcpconn_timeout interval in the web GUI) works just fine too, it's just a little kludgy in Thibor where he gives you a sexy GUI control to do it for you.

    Balancing the numbers:

    Make the connections table too small and the reuse time too high, and the connections table fills up and you can no longer make new connections until some free up, which causes lots of problems. Linksys' default is 2,048 connections and FIVE DAYS of timeout, which basically makes the router unuseable for P2P.

    Thibor's chosen default timeout is 600, which obviously works well for him, and is a good setting for a lot of people as it allows for a very small connections table, which is ideal because it keeps lots of memory free for more important things. If idle connections are being reused after 5 minutes, the chances of your exceeding 2,048 active connections is VERY low.

    For me, I need a larger timeout number since I make a lot of Telnet connections over VPN and I need to not have those timeout in 5 minutes (600 seconds), since that gets really irritating to me. so I have mine set at 14,400 (4 hours), which still gives me plenty of connection time but allows me to use P2P at the same time (I expanded my connections table out to 4,096 to acommodate P2P, since I can easily fill 2,048 connections in 4 hours on P2P).
     
  5. e1e0n

    e1e0n LI Guru Member

    Thank you for the explanation!

    Router runs solid rock :thumb: , I will try to tune it over weekend using your suggestions!

    Leo
     
  6. e1e0n

    e1e0n LI Guru Member

    Yesterday it worked like a rock until I didn't change conn. track table size via GUI. I suspect that this could be the source of problems. I changed size from 8192 to 4096 and after 1-2 hours it slowed down and finally I had to reboot is. I erased nvram one more time and reconfigured it and now it stable again.will try to repeat one more time latter to make sure that this could be the reason why it lost stability.
     
  7. eq2675

    eq2675 Network Guru Member

    I don't know why, but turning on QOS 4 weeks ago solved all my upload / disconnect issues.

    My whole network is / has always been set for an MTU of 1440 and I've gotten great results with the tweak test at dslreports.com . Just started having the upload / disconnect issue about 3 months ago. Tried different routers (Netgear), dsl modem, and MTU settings. Even went directly to my laptop with the dsl modem (Zyxel 642M) and same upload problems. Nothing helped.

    Then I turned on QOS with Thibor 14 on my WRT54GL. All problems soved.
     
  8. Bruticus

    Bruticus LI Guru Member

    Didn't Thibor14 contain this script already?

    echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
    echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
    echo "600 1800 120 60 120 120 10 60 30 120" > /proc/sys/net/ipv4/ip_conntrack_tcp_timeouts
     

Share This Page