Hi there. So I'm at my wits end with TCP Vegas. Half of the users apparently think it's doing something to their traffic, the rest are either indifferent or think it's doing something detrimental, and then there's the post supposedly by the guy that even ported it to the tomato base, calling it nothing more than "Snake Oil." I'm looking for the definitive answer; I can't get past the disinformation on this one.

Today we have things like CUBIC, are these implemented into the tomato kernel? Are they being used? Does this matter?
I initially tried to read up on this topic to ensure that was making the right decisions regarding proper traffic management and my connection and all I seemed to notice is that I may have been rubbing snake oil on a gaping wound for a long time now. If these are secrets that are unpublished, all I ask is that someone.

A congestion avoidance algorithm built into the Linux kernel, introduced in Tomato 1.23.

This may produce better results than QoS for some users. For example, users with connection speeds which vary considerably (cable users with "speed boost," or speed slows in the evening when everyone in the neighborhood goes online) are required to set QoS "Max Bandwidth" conservatively, to the lowest max speed encountered. They would never take advantage of higher speeds when available. In this case, TCP Vegas may be effective at dynamically adjusting speed while avoiding dropped packets which would occur if QoS "Max Bandwidth" were set aggressively (to the highest max speed encountered during day-to-day use.).

Some users have reported that a combination of TCP Vegas and QoS (with an aggressive "Max Bandwidth") works well. (This section requires additional feedback.).

TCP Vegas operates only on outbound traffic. However, some users have reported that changing its parameters affected inbound traffic. (This section requires expansion.).

So WTF is going on here? - The part i'm particularly interested in is where it mentions powerboost, because I have this it does tend to get complicated when QoSing… But apparently according to the guy that's implemented it in the firmware it's a non-issue and should be removed? I've tried sifting through the crap myself to no avail, please help.

If *ALL* of the three following conditions are true, Vegas _MAY_ help with latency _only on heavily congested networks_:

1. One of the endpoints *MUST* be *THE ROUTER ITSELF*. Thus, if you are just using "normal" Tomato, about the only thing it might help is the built-in FTP server, if you have one and have it directly on the Internet. If you are running third-party software on Tomato (transmission, Hiawatha, et al), then Vegas might actually help. If all of your software that actually creates TCP socket connections runs on clients sitting behind your router (Linux boxes, Windows boxes, Mac boxes, what have you), then enabling Vegas on the router _WILL DO NOTHING WHATSOEVER_, because the TCP packet headers that the algorithm modifies are created *ON THE ENDPOINT, NOT THE ROUTER* and that is the ONLY place they can be modified.

3. The other endpoint (on the other side of your TCP socket - see above) _SHOULD_ be using Vegas congestion avoidance as well for maximum effect. If they are using CUBIC, it _may_ benefit. If they are using Reno (the default with most router OSes, but not with Windows XP/Vista/7), Vegas (in the vast majority of cases) will actually make things _worse_.

In general, QoS is going to make a difference only with outbound traffic, where Vegas seeks to optimize _both endpoints_ of a TCP connection…which is why it's a damned good idea to have Vegas on both sides (and where the apps are *ACTUALLY RUNNING*, see point #1). One-way optimization will actually lead to madness, since the outcome is completely unpredictable.

Honestly, the biggest mistake I ever made with the Tomato project was entering into the "arms race" with DD-WRT and implementing Vegas. Fooling around with congestion avoidance is a lost cause unless you really know what you're doing (*particularly* behind an asymmetric connection like consumer-grade DSL, cable modem, or FiOS, since all of the inbound buffering is done at the ISP completely outside of your control). QoS, on the other hand, can produce very real, useful results if used with forethought and understanding of how IP communications works in general (and you accept up front that you will only ever be able to optimize the outbound leg of any connection).

So…since 99.99% of the population does NOT fall into the above categories, despite the fact that Vegas is indeed implemented and working in Tomato, it _is_ snake oil because it *cannot* and *will not* help them…and _ANY_ reports you have read otherwise are wishful thinking in complete ignorance of what TCP Vegas actually is and does.

I've tried my best to explain this time and again, and pointed people at the whitepapers written by the creator of the algorithm, all to no avail. If people refuse to listen, I really can't help that.

No, CUBIC is not in Tomato, and it never will be on my watch, because every single thing I said above also applies to CUBIC, and nobody's going to listen to me talk about how CUBIC is useless except in very special cases, either.

It may be useful for you to read up on Vegas (and congestion control in general), where you'll quickly come to understand that a) none of them really apply to asymmetric connectivity and b) all of the tests showing benefit are on closed-loop LANs with the same algorithm in use on both endpoints - in other words, a local test lab. Local test lab != low-speed consumer-grade asymmetric WAN connection crossing oceans.

This is the last I will ever write about this subject, simply because I have better things to do with my time than repeat myself every few months. If I had the means, I'd rip Vegas out of Tomato forever, because this "debate" seems to have no end whatsoever.

And I sincerely apologize for coming across as rude, but I hope you can appreciate my frustration. Your questions - and doubts - suggest strongly you haven't done much research on the subject, and have refused to believe what you've read from people that actually know what they are talking about. So, that having been said, use it if you want - it won't make any (positive) difference, and won't change my life one way or the other.

FYI, none of this has _anything_ to do with PowerBoost whatsoever - PowerBoost is a means of using header stripping and compression, in addition to edging channel boundaries out a bit, to try to appear to be faster than you really are. In practice, it is _also_ snake oil, but I lack the patience to rant any further about that…Google is your friend.

It's simply not possible to get something out of nothing, and there is no "magic bullet" that is suddenly going to make a home DSL connection start behaving like a bonded T3. The best you can hope for is to control the order of the bits you're sending out - that's it. If you want to go faster, buy a fatter pipe from your telco or cable provider.

Rodney, with all due respect, I think the OP has well accounted for your take on the situation. He, like myself, would like colaboration on all of your above flowing, confident, fluent EXplanatins, with some input from some alternate "authorative" source besides yourself, ( with all due respect, whoever the fuck you may be….)

I've never seen any benefit from Vegas, and I am a very heavy user of the very famous tomato QOS engine. If it indeed has no benfit then why do all the various flavors of Tomato still have the very skilled authors still writing this horse shit into the code ? Are Jonathan, VIC and Teddy all too busy to do a bit of house cleaning ? Why is there absolutely no evidence of it working properly, and yet it remains in the code, release after release ? Please don't answer again. You've had your say, we get your point, and it may indeed be exactly accurate. This is a thread looking to expand on what you have said, and I also would like to hear some alternate intelligent input.

I agree with every point Rodney made - if you start learning more about congestion control in Linux you will come to the same conclusions…

Are Jonathan, VIC and Teddy all too busy to do a bit of house cleaning ?

Two reasons Vegas stays in Tomato USB - at least for now:

You can potentially install a whole bunch of Optware on your router. See point (1) in Rodney's post - some of the applications running on the router may actually benefit from the congestion control.

Vegas is still a part of the official Tomato, and it's just much easier for me to keep it there than answer endless questions about where did it go, and why ;)…

Tomato QoS became famous long before Vegas was added to it. It's famous because it works - with or without Vegas, because nice GUI allowed users to configure and monitor it relatively easy, and because it worked a long time ago when the first versions of Tomato came out (and when QoS in DD-WRT suffered from lack of understanding and non-obvious GUI). Vegas has nothing to do with it, and I personally have it turned off.

Good post. Your frustrations don't go unnoticed. But the fact is, Google isn't always your friend. Go ahead and search for "Tomato TCP Vegas," with a clueless notion about what it is and you may notice that, as I stated previously, there's a mass amount of disinformation. I take your post as authoritative, but before reading this and your prior post there still lied the gleaming hope of what it was regarding the shaping of traffic and the dynamic nature of some inbound connections. If you didn't notice the "+show block" is directly quoted out of the wiki (regarding "speed boost"), I'm not making it up and it's still there. I'm certainly not sorry for "waking the dead," as it's provoked a more comprehensive description of what's going on and an affirmation that my suspicion in regarding your initial post in 2008 as accurate. Not that it matters, but I'm going to turn off vegas, now, after having it on for probably ~2 years. This information MAY be readily available but not definitive.[edit: ambiguous; meaning "Google searches"] Thanks for the addition and also to the two posters that added subsequently.

That being said: 1) Fix the wiki. 2) Possibly remove it from the GUI? (not altogether) 3) Educate users on what to do to properly manage traffic, and if QoS is all that's to be done, then so be it. Are there other sources? Aye, but there can never be too many and even better that some may agree. There is too much conflicting information floating around, period. You can also include the fact that I don't know you, who you are, and haven't worked with you, so it is hard to discern you or anyone else's post as fact. Although, as noted previously, I regard your latest post as authoritative in nature. Thanks again.

Thank you for taking the time to weigh in on the Vegas question. As the Op so succinctly stated, this Vegas issue has been a big question for a long time now, and your response has set it to rest. With the information and dis-information that has existed for a long time I fully sympathized with the questions he posed.

Thanks for your efforts and for making the fruits of your skills available for the rest of us to use. I will put more effort into maintaining a professional and courteous presence here on the forum.

There used to be discussion of QOS and Vegas in relation to speedmod - I assume this is a different Rodney?, but I see it is still alive and now incorporates the TC-ATM patch with hijacked source reference link

quoted text# To apply these patches, cd to the tomato directory and do 'patch -b -p1 <this_file'

Ray, thanks for the post, and yes, I would love to implement your solution to annihilate "Vegas" from my router. Unfortunately, I am just an ignorant waif who needs either a GUI checkbox to tick, or a script to copy and paste into one of the 4 admin script categories.