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

Enjoy gambling? Try Vegas (Tomato build included)!

Discussion in 'Tomato Firmware' started by rhester72, Nov 19, 2008.

  1. rhester72

    rhester72 Network Guru Member

    Enjoy gambling? Try TCP Vegas (Tomato build included)!


    All builds compiled with the Linksys v4.30.12 SDK and are *UNOFFICIAL*.

    Tomato 1.22 with TCP Vegas:


    Tomato 1.22ND with TCP Vegas:


    Tomato 1.22 with SpeedMod 8502 and TCP Vegas:


    Tomato 1.22ND with SpeedMod 8502 and TCP Vegas:


    IMPORTANT NOTE: Only use the ND (New Driver) builds if you know they are safe on your router! They *CAN* brick older routers!

    Source code (only for compilers):

    Tomato: http://multics.dynalias.com/tomato/tomato122_vegas.tar.bz2
    SpeedMod: http://multics.dynalias.com/tomato/tomato122-speedmod8502_vegas.tar.bz2

    The above source code should be unpacked *on top* of the Tomato or SpeedMod source code as the last step prior to compilation. Authors of other Tomato mods should be able to derive appropriate diffs for their source from the above. The TCP Vegas code was backported from the 2.4.27 kernel, which remains current as of

    IMPORTANT NOTE: If you are compiling from source and using SpeedMod 0101 (supplied with Tomato SpeedMod 1.22), you SHOULD NOT use the SpeedMod 8502 Vegas source - use the "regular" Tomato Vegas source.


    Q: What is TCP Vegas?
    A: TCP Vegas (http://www.cs.arizona.edu/projects/protocols/, http://en.wikipedia.org/wiki/TCP_Vegas) is a congestion control algorithm (http://en.wikipedia.org/wiki/TCP_congestion_avoidance_algorithm).

    Q: OK - what is a congestion control algorithm?
    A: The aim is to prevent backlog in the outbound network queue. Stock Tomato uses TCP Reno as the default (and only) CA. DD-WRT used TCP Westwood+ as the default in v24 and TCP Reno in v24 SP1, and additionally includes TCP Vegas and BIC. My build includes TCP Reno (the default) and TCP Vegas, but not TCP Westwood+ or BIC.

    Q: What is the big deal about including TCP Vegas in Tomato?
    A: Some DD-WRT users think it is the Second Coming(TM) (http://www.dd-wrt.com/phpBB2/viewtopic.php?t=28816). Others found it somewhat less useful (http://www.dd-wrt.com/phpBB2/viewtopic.php?t=30831). In theory, you should be able to uncheck the "Enable QoS" box in QoS/Basic Settings, enable TCP Vegas (see later FAQ entry), and have excellent congestion control without any further configuration. In reality, that may be true depending on your usage, but you may benefit from using TCP Vegas in conjunction with standard Tomato QoS and/or from tweaking TCP Vegas parameters (or may not benefit from TCP Vegas at all). Experiment and let us know your results!

    Q: Is this an experimental feature?
    A: It is something you can experiment with, but the code itself is quite mature/stable and has been part of the official Linux kernel since May 2004.

    Q: Is TCP Vegas enabled by default?
    A: No - by default, it will behave just like standard Tomato. See the question below on how to enable (and disable) it.

    Q: How do I enable TCP Vegas?
    A: Upgrade your Tomato firmware to a TCP Vegas-enabled build. Then, in Administration/Scripts/Init, put "echo 1 > /proc/sys/net/ipv4/tcp_vegas_cong_avoid" (without quotes) as the first line, Save, and reboot. TCP Vegas is now active!

    Q: How do I disable TCP Vegas after I have enabled it?
    A: Remove the tcp_vegas_cong_avoid line (above) from your Init script, Save, and reboot.

    Q: Is there anything I can "tweak" to improve TCP Vegas performance?
    A: You can experiment with the tcp_vegas_alpha and tcp_vegas_beta settings in /proc/sys/net/ipv4 (see the "Tuning Vegas" section at http://neal.nu/uw/linux-vegas/).

    Q: Can't I configure it with the Tomato web interface?
    A: No - web UIs are not my forte. It will likely show up in the GUI of a Tomato mod in the future, and hopefully in official Tomato someday.

    Q: Will TCP Vegas be included in future official Tomato builds?
    A: You'd have to ask Jon (the author). He's certainly more than welcome to.

    Q: I am a Tomato modder. Can I use your source in my build?
    A: Of course. It's not "my" source - it was originally authored by Neal Cardwell and is part of the official Linux 2.6 (and 2.4) trees. It's GPL - use and enjoy it!

    Q: Will you continue to release unofficial Tomato builds including TCP Vegas as new versions come out?
    A: Probably, depending on my available time and motivation. A link to download the modified source is near the top of the post, so anyone can carry the torch from here as it were.

    Q: Are you going to add TCP Westwood+ and BIC to Tomato in the future?
    A: Probably not. They are of limited usefulness on a SoHo router, and they just don't "scratch my itch". If someone else would like to, I'd recommend they backport the necessary changes from, since it makes switching between CAs a little less clunky. (DD-WRT users know all too well that earlier kernel revs allow you to select multiple CAs simultaneously, which is Not Good(TM).)

    You'll get the additional CAs "for free" if/when the Tomato kernel is upgraded to 2.4.27 or beyond (see next question/answer).

    Q: Since this is a kernel backport, does that mean that we will see a newer kernel in Tomato soon, so we can finally have support for multi-BSSID?
    A: That's not what it means at all. My efforts to forward-port Tomato to anything newer than the included 2.4.20 have thus far ended in miserable failure, though others may have more success. A newer kernel is very desirable for a whole host of reasons, but I'm afraid it won't be coming from me unless something magical happens.

    I also have it on good authority that the drivers in Tomato ND already support multi-BSSID, but Tomato as a whole does not (yet). Hi, Victek! *waves* :)

    Q: Why did you add TCP Vegas to Tomato?
    A1: Professional interest.
    A2: Personal research.
    A3: A burning desire to take away any possible advantage of the DD-WRT fanboys. :biggrin:


  2. Victek

    Victek Network Guru Member

    Great job Roodney !!! and is a pleasure to share your findings with the Tomato users.
  3. Disman_ca

    Disman_ca Super Moderator Staff Member Member

    Anyone try it yet?
  4. Victek

    Victek Network Guru Member

    One hour and a half after the post? .. premature, not? :biggrin:, you can try!
  5. dkirk

    dkirk Network Guru Member

    Yeah, I loaded up the Speedmod + Vegas on my WRT54GS v1 and it seemed to run fine with my voIP ViaTalk and TV over IP "SkyAngel" with QOS appearing to work, but only spent a few minutes watching it all. Will bang on Torrent tonight.
  6. peyton

    peyton LI Guru Member

    Have you got a list of old router which can be bricked ?
  7. rhester72

    rhester72 Network Guru Member

    No - the best way to tell is by examining wl0_corerev. If it is greater than 4, you ND should work, but may be flaky or provide no benefit. If it is 7 or greater, you almost certainly will benefit. If it is 4 or lower, you will brick.

  8. Dashiell

    Dashiell Network Guru Member

    Pardon my Linux Newbdom, but how would one do this? Is there a command from the telnet prompt?
  9. 4char

    4char Network Guru Member

    "nvram get wl0_corerev" should give you the value.
  10. Dashiell

    Dashiell Network Guru Member

    Thank you!

    I typed that into a telnet prompt and got back a value of "9". I guess I'm a good candidate for ND versions?

    PS - I should mention I'm running Victek's new 1.22 mod on the router in question. I notice Vic did not release an ND version this time around and I was told by another local user that it's because he's incorporated all the changes into his lone version. I am doubting this person's information, so I thought I'd ask...
  11. rhester72

    rhester72 Network Guru Member

    ND will always be separate. It must be.

    Yes, ND is a good choice for your hardware.

  12. averylinden

    averylinden Addicted to LI Member

    Thanks for this useful information. IMHO anything that can prevent a brick should be in the Tomato FAQ or wikibook.
  13. nvtweak

    nvtweak LI Guru Member

    Thank you for the source code

    It works well thanks! :biggrin:
  14. vanhh

    vanhh Network Guru Member

    how come there is no '.bin' files in ND version? If '.trx' and '.bin' are the same, then how do I flash it? Flash it just like regular '.bin' file? Thanks.
  15. nvtweak

    nvtweak LI Guru Member

    probably because the ND version was originally made for a Buffalo router and noone compiles it otherwise

    It might be that Tomato can flash it no matter the filename, I'm not sure. AFAIK all the filename/extension really refers to is the type of header the firmware uses.
  16. rhester72

    rhester72 Network Guru Member

    I routinely flash trx directly from the Tomato interface. bin is only needed for initial (read: fresh-out-of-the-box) install.

  17. nobugme

    nobugme Network Guru Registered

    My WRT54GS v1.1 value is 7 (running standard tomato 1.22) but you told me in the other tread that GS 1.1 does not support ND. So will it brick or will I benefit, and how will I then benefit? :S

  18. mstombs

    mstombs Network Guru Member

    I have one of these, and when I tried to load a ND version through web interface a while ago it wouldn't take it. I never bothered to try via tftp, don't really have an issue with wireless even with an Intel laptop which is an area it is supposed to help.
  19. rhester72

    rhester72 Network Guru Member

    I could have sworn the other thread I responded to was about a 54G 1.0, which is most definitely not compatible with ND. The 54GS 1.1 is.

    As for how you will benefit, outside of multi-SSID (which is not supported), the biggest advantage is stability with Intel mobile chipsets. If you are having issues with random reboots, try ND. If not, you are fine as-is.

  20. rhester72

    rhester72 Network Guru Member

    Loading ND through the manufacturer's interface doesn't work so well. Your best bet is to load non-ND and then upgrade to ND from within the Tomato interface, which works just fine.

  21. Disman_ca

    Disman_ca Super Moderator Staff Member Member

    Sorry, I didn't even look to see when it was posted. My bad
  22. TVTV

    TVTV LI Guru Member

    I ran a "nvram get wl0_corerev" via SSH on my WRT54GL v1.1 and it returned a 9. So i've procedeed to installing Tomato 1.22-ND. So far it works like a c.h.a.r.m.
  23. Kiwi8

    Kiwi8 LI Guru Member

    Is it true? I have a WRT54G 2.0 and it returned 7 for that variable. :)

    This means that almost all WRT54Gs can support the ND firmware? :confused:
  24. rhester72

    rhester72 Network Guru Member

    Support != benefit. If you aren't having stability issues, there's no pressing reason to move to ND (yet).

  25. Kiwi8

    Kiwi8 LI Guru Member

    By the way, do TCP Vegas need to be enabled on all routers connected to the main router, or it need be enabled on only the main router?
  26. Kiwi8

    Kiwi8 LI Guru Member

    Another question is, to disable TCP Vegas, instead of removing the line, can we put zero into the variable?

    As in:
    echo 0 > /proc/sys/net/ipv4/tcp_vegas_cong_avoid
  27. rhester72

    rhester72 Network Guru Member

    It only needs to be on the main router and can be disabled by stuffing the register with a zero.

  28. regular

    regular LI Guru Member

    how would I confirm that it is working via telnet? is there anything I can type in to check?

    also would resetting the nvram be necessary if I'm upgrading from your prior speedmod version 1.21?
  29. rhester72

    rhester72 Network Guru Member

    # cat /proc/sys/net/ipv4/tcp_vegas_cong_avoid


  30. regular

    regular LI Guru Member

    thanks a lot for that info!
  31. Toastman

    Toastman Super Moderator Staff Member Member

    TCP Vegas installed on a router has no effect whatsoever. It must be used at the source - on your PC. Traffic passing through the router doesn't use TCP Vegas. Traffic originating from the router, such as a router with built in NAS on a USB port or whatever, MIGHT have some benefit from it. But normally, it must be in use at both ends of the link to have a useful benefit.
  32. vanhh

    vanhh Network Guru Member

    Can we enable TCP Vegas via telnet? Would it work?
  33. rhester72

    rhester72 Network Guru Member

    Yes and yes.

  34. der_Kief

    der_Kief Super Moderator Staff Member Member

    Put it to Tomato Modifications and Poll thread :biggrin:

  35. Mastec

    Mastec Network Guru Member

    You can rename a trx file extension to bin then you can flash it using the GUI.

    tomato-ND.trx --> rename to tomato-ND.bin --> Flash

    Works too, did it all the time with my Buffalo
  36. pharma

    pharma Network Guru Member

    Working fine on a WRT54G 1.1 and WRT54G v4.

    Thanks Rodney! :)

  37. Mastec

    Mastec Network Guru Member


    Tomato 1.22ND with SpeedMod 8502 and TCP Vegas working on my WL500gP v2
  38. dkirk

    dkirk Network Guru Member

    Small problem

    When I try that command from the command prompt it comes back with "nonexistent directory". That command is correctly in the Init script and yet the file is not created. If I try at the command prompt, in that directory something simple as "echo 1 > test" same thing, nonexistent directory. Any ideas? I'm logged in as Root.
  39. rameshb_v

    rameshb_v LI Guru Member

    How do we set priority using TCP Vegas ? Is there anything where we can give priority like QOS ? Thx
  40. rhester72

    rhester72 Network Guru Member

    Can you copy/paste the terminal output, as well as the output of "ls -l /proc/sys/net/ipv4"?

  41. rhester72

    rhester72 Network Guru Member

    Vegas is not QOS, it is congestion control. You can tune the alpha and beta parameters as indicated in the FAQ.

  42. Kiwi8

    Kiwi8 LI Guru Member

    I realised that even after TCP Vegas is enabled, I still need to enable QOS, otherwise when I play TV stream, it will lag my games.
  43. rameshb_v

    rameshb_v LI Guru Member

    Thanks... I need to enable QOS on TOP of Vegas to have the faster IE during torrents.
  44. dkirk

    dkirk Network Guru Member

    unknown login: root

    Tomato v1.22.1570

    BusyBox v1.12.2 (2008-11-16 03:35:24 PST) built-in shell (ash)
    Enter 'help' for a list of built-in commands.

    # ls -l /proc/sys/net/ipv4
    dr-xr-xr-x 7 root root 0 Nov 23 14:19 conf
    -rw-r--r-- 1 root root 0 Nov 23 14:19 icmp_echo_ignore_all
    -rw-r--r-- 1 root root 0 Nov 23 14:19 icmp_echo_ignore_broadca
    -rw-r--r-- 1 root root 0 Nov 23 14:19 icmp_ignore_bogus_error_
    -rw-r--r-- 1 root root 0 Nov 23 14:19 icmp_ratelimit
    -rw-r--r-- 1 root root 0 Nov 23 14:19 icmp_ratemask
    -rw-r--r-- 1 root root 0 Nov 23 14:19 igmp_max_memberships
    -rw-r--r-- 1 root root 0 Nov 23 14:19 inet_peer_gc_maxtime
    -rw-r--r-- 1 root root 0 Nov 23 14:19 inet_peer_gc_mintime
    -rw-r--r-- 1 root root 0 Nov 23 14:19 inet_peer_maxttl
    -rw-r--r-- 1 root root 0 Nov 23 14:19 inet_peer_minttl
    -rw-r--r-- 1 root root 0 Nov 23 14:19 inet_peer_threshold
    -rw-r--r-- 1 root root 0 Nov 23 14:19 ip_autoconfig
    -rw-r--r-- 1 root root 0 Nov 23 14:19 ip_conntrack_max
    -rw-r--r-- 1 root root 0 Nov 23 14:19 ip_conntrack_tcp_timeout
    -rw-r--r-- 1 root root 0 Nov 23 14:19 ip_conntrack_udp_timeout
    -rw-r--r-- 1 root root 0 Nov 23 14:19 ip_default_ttl
    -rw-r--r-- 1 root root 0 Nov 23 14:19 ip_dynaddr
    -rw-r--r-- 1 root root 0 Nov 23 14:19 ip_forward
    -rw-r--r-- 1 root root 0 Nov 23 14:19 ip_local_port_range
    -rw-r--r-- 1 root root 0 Nov 23 14:19 ip_no_pmtu_disc
    -rw-r--r-- 1 root root 0 Nov 23 14:19 ip_nonlocal_bind
    -rw-r--r-- 1 root root 0 Nov 23 14:19 ipfrag_high_thresh
    -rw-r--r-- 1 root root 0 Nov 23 14:19 ipfrag_low_thresh
    -rw-r--r-- 1 root root 0 Nov 23 14:19 ipfrag_time
    dr-xr-xr-x 6 root root 0 Nov 23 14:19 neigh
    dr-xr-xr-x 2 root root 0 Nov 23 14:19 route
    -rw-r--r-- 1 root root 0 Nov 23 14:19 tcp_abort_on_overflow
    -rw-r--r-- 1 root root 0 Nov 23 14:19 tcp_adv_win_scale
    -rw-r--r-- 1 root root 0 Nov 23 14:19 tcp_app_win
    -rw-r--r-- 1 root root 0 Nov 23 14:19 tcp_dsack
    -rw-r--r-- 1 root root 0 Nov 23 14:19 tcp_ecn
    -rw-r--r-- 1 root root 0 Nov 23 14:19 tcp_fack
    -rw-r--r-- 1 root root 0 Nov 23 14:19 tcp_fin_timeout
    -rw-r--r-- 1 root root 0 Nov 23 14:19 tcp_keepalive_intvl
    -rw-r--r-- 1 root root 0 Nov 23 14:19 tcp_keepalive_probes
    -rw-r--r-- 1 root root 0 Nov 23 14:19 tcp_keepalive_time
    -rw-r--r-- 1 root root 0 Nov 23 14:19 tcp_max_orphans
    -rw-r--r-- 1 root root 0 Nov 23 14:19 tcp_max_syn_backlog
    -rw-r--r-- 1 root root 0 Nov 23 14:19 tcp_max_tw_buckets
    -rw-r--r-- 1 root root 0 Nov 23 14:19 tcp_mem
    -rw-r--r-- 1 root root 0 Nov 23 14:19 tcp_orphan_retries
    -rw-r--r-- 1 root root 0 Nov 23 14:19 tcp_reordering
    -rw-r--r-- 1 root root 0 Nov 23 14:19 tcp_retrans_collapse
    -rw-r--r-- 1 root root 0 Nov 23 14:19 tcp_retries1
    -rw-r--r-- 1 root root 0 Nov 23 14:19 tcp_retries2
    -rw-r--r-- 1 root root 0 Nov 23 14:19 tcp_rfc1337
    -rw-r--r-- 1 root root 0 Nov 23 14:19 tcp_rmem
    -rw-r--r-- 1 root root 0 Nov 23 14:19 tcp_sack
    -rw-r--r-- 1 root root 0 Nov 23 14:19 tcp_stdurg
    -rw-r--r-- 1 root root 0 Nov 23 14:19 tcp_syn_retries
    -rw-r--r-- 1 root root 0 Nov 23 14:19 tcp_synack_retries
    -rw-r--r-- 1 root root 0 Nov 23 14:19 tcp_syncookies
    -rw-r--r-- 1 root root 0 Nov 23 14:19 tcp_timestamps
    -rw-r--r-- 1 root root 0 Nov 23 14:19 tcp_tw_recycle
    -rw-r--r-- 1 root root 0 Nov 23 14:19 tcp_tw_reuse
    -rw-r--r-- 1 root root 0 Nov 23 14:19 tcp_window_scaling
    -rw-r--r-- 1 root root 0 Nov 23 14:19 tcp_wmem
    # echo 1 > /proc/sys/net/ipv4/tcp_vegas_cong_avoid
    -sh: can't create /proc/sys/net/ipv4/tcp_vegas_cong_avoid: nonexistent directory

    After loading your firmware I executed a full clear of the nvram, just be sure all is factory default.
  45. rhester72

    rhester72 Network Guru Member

    The firmware load must have failed, because there is definitely no Vegas support on the one you are currently running.

  46. lwf-

    lwf- Network Guru Member

    Using ND version on my WRT54GS 1.1, Vegas and QoS enabled. I cannot difference in performance, but it was fine before and so far it appears to work fine now as well.
  47. XMoA

    XMoA Addicted to LI Member


    I'm using you ND+VEGAS on my WHR-125G

    I'm using QOS + VEGAS (3 lines)

    Super super solid and fast !!

    I will report if there are some unstable things !
  48. XMoA

    XMoA Addicted to LI Member

    muahahha it's me again

    it's too amazing :D

    i have 4500 connections and response time it SUPER FAST :D

    testing testing :biggrin:
  49. i1135t

    i1135t Network Guru Member

    Actually my trials of Vegas is somewhat questionable. With it on set to:


    I get drops with my VoIP on heavy load (torrents, browsing, etc etc) and even issues signing on.

    But when I set:


    as stated in the Tuning section Rodney provided.

    I get good VoIP with heavy load, but somewhat, but not huge, laggy response with browsing..

    So, right now, I have it set to default settings


    and appears to be OK, for now, but will have to test it on heavy load.

    Anyhow, just wanted to share my experiences... thanks anyways..

    Oh, forgot to mention, I have QOS enabled, for all settings, as I want to ensure VoIP has the highest priority above all. Haven't tried it without it, but if I do, I will repost.

    Thanks Rodney and all who contributed in making this happen... THANKS again!!!

    -- EDIT --

    OK looks like I had it wrong in the earlier posting:


    are the default settings, and with settings of:


    I still get somewhat small, but noticable lag with web browsing with heavy load of torrents. VoIP seems OK though.

    Next thing is to just disable QOS. I will repost my results later.

    -- EDIT --

    Wow, I am impressed... Vegas at default settings appear to be working great with QOS disabled... cool!! Thanks!!!
  50. quirK

    quirK LI Guru Member

    If Vegas is enabled via telnet, does the setting stick across reboots? Are there commands to confirm that Vegas is currently enabled?

    Thanks for this mod... very cool technology going on in my humble WRT54GL. :biggrin:
  51. wasp87

    wasp87 Network Guru Member

    I have set

    echo 1 > /proc/sys/net/ipv4/tcp_vegas_cong_avoid
    echo 3 > /proc/sys/net/ipv4/tcp_vegas_alpha
    echo 3 > /proc/sys/net/ipv4/tcp_vegas_beta

    and have experienced fine results. Very fast downloading, less lag when multiple computers gaming online together.
  52. arikam

    arikam Addicted to LI Member

    yeah that setup works great for me too, I went to Vegas and I'm not going back :thumbups:
  53. wasp87

    wasp87 Network Guru Member

    I'm still not sure about what I'm going to do. Now I've read Westwood may be better than Vegas or Reno may even be better than Vegas.

    Apparently Vegas wastes available bandwidth, but how fast I've been downloading, it's hard to believe I'm wasting any since I'm getting faster speeds than my ISP even rates my plan at. Except they have some speed boost thing for big downloads. *Using Cox 12.5Mbps/1.5Mbps*
  54. TVTV

    TVTV LI Guru Member

    I haven't noticed any difference in download/upload speeds since i've enabled Vegas, and i'm on a 50 mbps line (fiber).
  55. rhester72

    rhester72 Network Guru Member


    # cat /proc/sys/net/ipv4/tcp_vegas_cong_avoid

    If you get a 1, it's enabled - a 0 means disabled.

  56. quirK

    quirK LI Guru Member

    Thank you!
  57. wasp87

    wasp87 Network Guru Member

    Do you need to telnet into the router in order to send it that?
  58. rhester72

    rhester72 Network Guru Member

    Telnet or ssh, yes. I believe the current test build has a GUI that handles all this.

  59. Sunspark

    Sunspark LI Guru Member

    The test build of tomato came pre-set with:

    Alpha: 2
    Beta: 6
    Gamma: 2

    Does anyone know how to determine whether these are better #s than 1-3-1 or some other combo?
  60. averylinden

    averylinden Addicted to LI Member

    The best settings are probably dependent on how you use your network. Apart from the tomato defaults, the only other recommend settings I've seen are 3-3-2 (from here: http://neal.nu/uw/linux-vegas/). These give a very slight performance edge in my setup (2 users, heavy vpn, occasional torrent) over the defaults. Benchmark different settings yourself and choose the best one.
  61. Dashiell

    Dashiell Network Guru Member

    This question may be redundant, but...

    I am assuming that if you can type

    "echo 0 > /proc/sys/net/ipv4/tcp_vegas_cong_avoid"

    to disable Vegas, you could also do the same for the alpha, beta and gamma apps?


    "echo 0 > /proc/sys/net/ipv4/tcp_vegas_alpha"
    "echo 0 > /proc/sys/net/ipv4/tcp_vegas_beta"
    "echo 0 > /proc/sys/net/ipv4/tcp_vegas_gamma"

    no quotes, naturally.

    Someone please send me a clue if I am mistaken.
  62. rhester72

    rhester72 Network Guru Member

    Alpha, beta and gamma are not apps but are Vegas configuration parameters. 0 is not a valid option for any of them. Alpha and beta are measured in half-packets and gamma only has a valid value of 2. Please see the FAQ page under Vegas configuration for details.

  63. Sunspark

    Sunspark LI Guru Member

    I read an academic paper discussing how to 'tune' vegas a bit for 'fairness' to interact well with TCP Reno.

    The authors recommended using alpha and beta values of 3 as opposed to alpha 1-beta 3.

    So I guess that means 6-6-2.

    Anyone want to try that one out?

    If you want to read the paper (long, w/ graphs) http://www4.comp.polyu.edu.hk/~csrchang/MSc/estella.pdf
  64. Sunspark

    Sunspark LI Guru Member

    Isn't there anyone with a heavily used connection from multiple sources that can help test?

    Vegas is half-packets so, settings to use:

    Gamma always at 2 (1 full packet, leave it at this).

    Config 1:
    Alpha - 2 (1)
    Beta - 6 (3)

    Alpha - 6 (3)
    Beta - 6 (3)

    Alpha - 3 (1.5)
    Beta - 3 (1.5)

    I'd be curious to see what results the 3 configs generate.
  65. gsan

    gsan LI Guru Member


    how to set those value?
  66. rhester72

    rhester72 Network Guru Member

    echo 1 > /proc/sys/net/ipv4/tcp_vegas_cong_avoid
    echo 1 > /proc/sys/net/ipv4/tcp_vegas_alpha
    echo 3 > /proc/sys/net/ipv4/tcp_vegas_beta

    To be fair, however, I'm surprised those values produce useful results.

  67. Sunspark

    Sunspark LI Guru Member

    gsan, to get that you have 2 in the alpha box, and 6 in the beta box.

  68. averylinden

    averylinden Addicted to LI Member

    Here's my totally unscientific test, which backs up what I saw before. While downloading a torrent with 70 seeds generating about 200 kB/s d/l and 100 kB/s upload (max'd), I ran 2 speed tests at speedtest.net at each vegas setting, averaging the two runs.

    2-6-2 (tomato default)

    93.5 ms ping
    4902.5 kbps d/l
    377 kbps u/l


    81 ms ping
    5355.5 kbps d/l
    409 kbps u/l


    69.5 ms ping
    4331 kbps d/l
    317.5 kbps u/l

    The last setting had a good latency but unimpressive throughput compared to the other two. I'm sticking with my 3-3-2. :)
  69. Sunspark

    Sunspark LI Guru Member

    Yeah, what i1135t has done, is set it so there's a queue between .5 and 1.5 packets. It is a bit on the low side.

    I'm currently trying Alpha=Beta at 3 half packets (or 1.5 full packets).

    You know, honestly, the way it's been set up with the half and full packets confuses a lot of people.

    In Tomato folks the # you enter into the box is the number of half packets. The # in brackets immediately to the right is the translated full packet value.

    So 4 half packets = 2 full packets. It's fractions.

    0.5 * 4 = 2
  70. mstombs

    mstombs Network Guru Member

    Linksys WRT54GL 4.30.13 now available on ftp site to download
  71. Toastman

    Toastman Super Moderator Staff Member Member


    mst - did you see anything interesting or new?

    Anyway, so many people reporting huge improvements from TCP Vegas, when it isn't even used for connections passing through the router. This is very interesting from the point of view of a developer, because it means that glowing reports on forums don't mean very much at all.

    The PLACEBO effect in action!
  72. mstombs

    mstombs Network Guru Member

    Didn't find any release notes, you can see from the file dates there are changes to dhcpcd, ntp, ddns, l2tp and binary only rc and web interface files etc. Doubt if any of these files are used in Tomato.
  73. jyavenard

    jyavenard Network Guru Member

  74. mstombs

    mstombs Network Guru Member

    OT but as Victek has pointed out the GPL source for WRT160n_v1.53.0_etsi.tgz contains a 7MB library object module for REL_4_150_10_16 (2007.10.4) which runs on nominally the same Linux 2.4.20 kernel!
  75. Toastman

    Toastman Super Moderator Staff Member Member

    mstombs, I see a glimmer of light at the end of the tunnel!
  76. bhlonewolf

    bhlonewolf LI Guru Member

    Cool I see Vegas is included in 1.23 -- I haven't tried it yet, but I'm curious: what would be the advantage of using both QoS and Vegas?
  77. az2008

    az2008 Addicted to LI Member

    The DD-WRT people were raving about TCP Vegas:


    If you read that entire thread, you'll find two different positions:

    1. Some people seemed to say that using TCP Vegas with no QoS was better.
    2. Others seemed to say that setting QoS bandwith to 0 (no limit?) and using TCP Vegas too was better. (Let QoS traffic shaping occur, but let TCP Vegas handle the congestion avoidance, throttling the speed as necessary.).

    Which works best probably depends on whether you have a relatively fixed and predictable bandwidth (like DSL):

    1. If your speed varies a lot (Cable "speed boost" or cable's reputation for slowing down during prime time due to neighbors sharing the same loop) TCP Vegas may be better because you wouldn't be forced to set the QoS bandwidth to the *lowest* speed you regularly experience (a requirement for QoS to work effectively).

    2. If you have a constant speed (like DSL), QoS may work better because you know what to expect. No reason to let TCP Vegas push the envelope and discover your max speed through latency, etc.

    The interesting thing to me is, in the case of #1, what would be the benefit of using both QoS and TCP Vegas. Setting bandwidth to 0, and letting TCP Vegas discover speed (as it varies) and still taking advantage of shaping.

    I suppose another factor is whether we're discussing upload or download. From what I've read, TCP Vegas is only for avoiding upload congestion. Similarly, I've read that QoS is really for upload. There's really no way to shape download traffic. It's just a matter of delaying acknowledgments, throwing away packets, causing the sender to slow down and resend.

    If both of those assumptions are true, then a person might want to use Tomato's QoS only for download. Although it's not truly "QoS" (traffic shaping), it does work effectively. In this case, I could see specifying max bandwidth for incoming QoS. But, specifying 0 for outgoing, letting TCP Vegas handle the pacing (while Tomato applies prioritization to packets).

    Anyway, with these different factors, it's probably possible for different people to have different feelings about how well TCP Vegas works, or if it should be used in combination with QoS, or not used at all, or exclusively.

    If what I've read is true (about both TCP Vegas and QoS), this might mean that it would be useful to have the option to enable incoming and outgoing QoS independently. I might want to use TCP Vegas exclusively for outgoing (because I have variable upload speeds), but QoS for incoming (because it's better than nothing).

    I guess the big question is whether my assumptions are correct (1. TCP Vegas only operates on outbound traffic. 2. Inbound QoS isn't really traffic shapping, just a kludgy, yet effective way to force the sender to slow down.). If these two are correct, then it's interesting to contemplate how they might work together, or not.

  78. bhlonewolf

    bhlonewolf LI Guru Member

    Thanks Mark!

    I'll play around with it. I'm in exactly that situation where I have to use the lowest max speed I've seen on my connection (cable), which is restricting me 80% of the time to get predictable results. I might not mind if I were on a 15mb up/down connection, but on my measly upload (512k up) it stinks. So, Vegas seems very interesting in that regard. I'll have to give it a try.

    What didn't make sense to me (and still doesn't, actually :)) is how Vegas determines priority, which I suppose is where QoS comes in. The typical case for me is: Using VOIP while downloading/uploading/online conference meeting from home. In this case, my VOIP must have it's full 90k, but the others can scale appropriately. If I keep my QoS to 415k upload, it works perfectly all the time.
  79. bripab007

    bripab007 Network Guru Member

    I have a variable speed cable connection (effing Comcast, if you must know :thumbdown: ), and I would love to be able to effectively get/use all the bandwidth available to me at off-peak hours, but I just don't think it's feasible for me to not use QOS settings.

    I play games on Xbox Live and do some FTP'ing and Bit Torrenting, and to be able to do these things simultaneously, all while the wife is surfing, is just not possible using only TCP Vegas.

    So I tried turning QOS using unlimited (well, 999999kbits) bandwidth for both inbound and outbound, but it just causes incredibly high ping and latency times.

    Anyone got any other ideas for us poor variable bandwidth yahoos?:tongue:
  80. Kye-U

    Kye-U Addicted to LI Member

    Just did some speedtests with different A/B/G values, and thought I'd share:




  81. peyton

    peyton LI Guru Member

    What about the latence ? Did it change something ?
  82. az2008

    az2008 Addicted to LI Member

    Interesting that your download speed changed so much. I've read that TCP Vegas only operates on outgoing packets. I don't understand why changing the parameters would affect the download, unless it delayed outbound packets (and acks) that the torrents expected, causing them to wait(?).

  83. Toastman

    Toastman Super Moderator Staff Member Member

    You got it .... Vegas doesn't work on connections passing through a router.


    So many posts recommending people to enter 99999999 or whatever in QOS outbound and inbound maximum settings. This is gross misinformation, and QOS cannot work with these settings. You have effectively turned QOS off.
  84. Toastman

    Toastman Super Moderator Staff Member Member


    You can't use QOS with outbound limit set that high - i.e. no limit. It will swamp your router with incoming replies to your P2P. Set it to, say, 70% of your upload bandwidth, and try no limit on incoming and see how that works. You will then be using QOS to give priorities only, which is what you maybe wanted?


    For all intents and purposes your posted tests show no significant changes at all between the different settings.
  85. az2008

    az2008 Addicted to LI Member

    The theory (and some reports of positive results among DD-WRT users) is that you set your outbound "Max Bandwidth" to unlimited (in DD-WRT that's supposed to be "0"; in Tomato 9999999), and let TCP Vegas manage how fast the data is sent.

    TCP Vegas operates only on outbound traffic.

  86. bripab007

    bripab007 Network Guru Member

    Toastman, just to reiterate what Mark said: Tomato's QOS only acts on oubound traffic, so setting the Max Inbound Bandwidth to 999999 (read: "unlimited") just means that I'm letting TCP Vegas and my ISP's traffic-shaping algorithms/hardware control my download speed.

    This is what you want, since you really have no meaningful control over incoming packets once they reach the end-user (read: me) anyway.
  87. az2008

    az2008 Addicted to LI Member

    That's not quite what I said. I said TCP Vegas only acts on outbound traffic.

    Personally, I have found Tomato's inbound QoS to be extremely effective. I understand that it's not "QoS" in a literal, technical sense. It's just delaying acks, dropping packets, to hopefully cause the sender to slow down. But, for me, (with 1500kbs/250kbs) it makes a big difference using VOIP.

    I have demonstrated it to myself by saturating my bandwidth using www.speedtest.net while on a call. During the download test the quality of the call isn't as good as during the upload test. But, it's worlds better than without Tomato's inbound QoS-like trickery.

    This might be due to my relatively slow speed. If someone had 6000kbs down, they might not notice the difference as much as I do. VOIP only requires 30kbs to 100kbs (depending on the codec used). I don't want to say everyone should use inbound "QoS" just because I notice a significant improvement. But, it's worth trying. Especially for slower connections.

  88. kripz

    kripz LI Guru Member

    az2008, i have set my outbound rate to 99999, what do i set the %'s to?
  89. az2008

    az2008 Addicted to LI Member

    Sorry, I can't answer that. It's very subjective. Minimums=60,20,10,5,5? Maximums=100?

    It all depends on what you want to accomplish. Outbound 99999 may not be best for you either. It seems to vary from individual to individual. Some people find outbound QoS works better. Others find TCP Vegas works better. Others find a combination of the two is better.

  90. Toastman

    Toastman Super Moderator Staff Member Member

    Look, guys. This is getting really ridiculous. Some idiot says something somewhere and everybody is following like sheep? "Incoming" QOS doesn't work? It's a bandwidth limiting function and cause the incoming streams to slow down by dropping packets. That is a perfectly normal, ESSENTIAL function of TCP/IP itslef, without which the internet could not even work. Yet people say "it doesn't work" ????

    Re. the 9999999 setting:

    OK, I just set my outgoing QOS limit to 99999. Immediately, P2P took 372 kbps - which is my absolute maximum outgoing bandwidth. (BTW - this is not MY P2P, but the collective P2P by the residents of this block, looked like about 7 online at the time).

    Download speed increased to absolute maximum for this ADSDL line (2.2Mbps) , as one would expect. The incoming bandwidth graph has flat-topped, indicating a big queue built up at the ISP.

    Opening a HTTP session to my favorite test server showed that the test page took between 7-12 seconds to load - instead of the normal 3-4 seconds. IPTV became unusable.

    Switching off QOS altogether makes no difference under these conditions. It's clear that the router's transmit buffer is full and QOS is totally unable to function.

    Why I'm even bothering to do this I have no idea. It's completely pointless anyway. All these people claiming QOS doesn't work when they obviously have not even tried it, based on something somebody said on some forum somewhere (usually DDT) who probably read it in a comic book.

    Question - did the DD-WRT guys mean to replace INCOMING limit with 999999?? That would at least make sense, and would allow QOS to work. Otherwise I assume the people on those forums are talking out of their ass.
  91. heh2k

    heh2k Addicted to LI Member

    This whole effort and thread is pointless. Turning on Vegas in a router is not going to affect routed traffic. Window size and send rates are determined by end points, not routers. Netfilter does not rewrite windows or buffer tcp streams, and doing so would cause unwanted interactions between the router and end points' tcp stacks.

    If you want tcp vegas, enable it on your computers, not router. But cubic is better anyway.
  92. quirK

    quirK LI Guru Member

    heh2k, you... prefer to discount the real-life results of routers with TCP Vegas as supernatural occurrences? :)

    It takes foolhardiness to claim something in the face of evidence which indicates otherwise.
  93. Toastman

    Toastman Super Moderator Staff Member Member

    heh2k is 100% right. It doesn't work. It doesn't even get used. This should teach all of us a lesson!
  94. heh2k

    heh2k Addicted to LI Member

    Routers don't do tcp congestion control, even when doing nat. If they did, it would cause unwanted state interactions at each router - just think about tcp slow start happening at every hop! The way any tcp stream reacted would depend on how many routers the packets went thru - the internet would simply not work. Then there's all the cpu cycles you'd need to run the tcp algorithms and all the ram to handle millions of tcp states. That's not what routers do.

    For the record, I think Tomato is great, very easy to use - I'm using it right now to send this. I'm just telling you guys that enabling vegas will only affect connections to and from the router - NOT connections that are routed thru, even if you're using netfilter and conntract (which is how tomato does nat).

    If you don't believe me, download the linux source and look for yourself.

    grep for these fuctions: cong_avoid tcp_rcv_established tcp_v4_do_rcv backlog_rcv ucopy.prequeue sk_receive_skb netif_rx

    in these files: net/netfilter/*.c net/ipv4/netfilter/*.c

    tcp_vegas_cong_avoid() never gets called by netfilter!
  95. mstombs

    mstombs Network Guru Member

    I have always wondered how TCP_Vegas works, before it was an option in Tomato (thanks Rodney!) folk suggested that it was dd-wrt QOS that was broken and the benefit reported by using Vegas in place of QOS was all due to turning off QOS.

    Is there anything special about wireless and pppoe connections that use virtual interfaces in the nat/masquerade router/gateway? What about using ssh or vpn tunnels with endpoint in the router? Do dnsmasq lookups from the router benefit (doubt it not streaming data?).

    Note - I don't know how QOS or TCP work in detail. I'm pretty sure I want QOS when my upstream bandwidth is challenged so VOIP takes priority over p2p or big downloads for example. I was hoping that congestion control would be better at slowing down connections by delaying rather than just dropping packets - which just leads to inefficient repeat message traffic over LAN/WLAN
  96. yoda

    yoda Addicted to LI Member

    so what does tcp_vegas do?
  97. wasp87

    wasp87 Network Guru Member

    So is it concluded everyone should disable TCP Vegas?

    I'm still using it with 3-3-2 settings working flawlessly.
  98. rhester72

    rhester72 Network Guru Member

    There is no need to disable Vegas, just don't expect it to do anything useful except under rare and unusual circumstances (assuming normal router usage). It can't/won't hurt anything.


Share This Page