how-to block ads
|
KodiacZiller
join:2008-09-04
73368
| reply to amigo_boy
Re: Giving priority to MJ traffic (Qos, Tomato firmware)
Thanks for the tutorial.
One thing. In step 6 you link to another post where you explain how to use Wireshark in order to determine the proxy. You don't need to do that with Tomato. All you have to do is click the little "Automatically resolve IP address" check box on the "View Details" screen when placing a test call. This will resolve all IP addresses in the list and you can clearly see both the proxy1 and VMS name resolutions. | |
amigo_boy
join:2005-07-22
Tempe, AZ
 ·Cox HSI
 ·magicjack.com
 ·EarthLink
| said by KodiacZiller  :In step 6 you link to another post where you explain how to use Wireshark in order to determine the proxy. You don't need to do that with Tomato. All you have to do is click the little "Automatically resolve IP address" check box on the "View Details" screen when placing a test call. This will resolve all IP addresses in the list and you can clearly see both the proxy1 and VMS name resolutions. Thanks. I didn't think of that.
I should have also added a suggestion to set the priority for the two rules to "lowest." Then do the simultaneous echo and speed tests. MJ should be noticeably degraded if the rules are applying.
(If someone has extremely high speeds, like FIOS, maybe not. They'd have to concoct their own tests to put a load on their connection. For me, at 256/1500, setting the rule to "lowest" makes MJ completely unusable during the speed test. No voice gets through at all. So, I definitely know the rule is being applied.).
Mark | |
amigo_boy
join:2005-07-22
Tempe, AZ
·Cox HSI
·magicjack.com
·EarthLink
edit:
October 22nd, @04:23PM
| I should add that I played with the inbound QoS. It works well.
On the QoS -> Basic Settings page,
....- Set the "Inbound limit" to the speed you regularly get when performing a test at speedtest.net. (Do the speedtest with no other activity. If you get different speeds, use the lowest.).
....- Set "Highest" to 100%.
That's all their is to it. I was skeptical about this because I've read there's no way to do inbound QoS (because your router can't control the speed at which someone else's router sends data to you. But, I guess it slows down sending acknowledgments which causes the sender to slow down?).
But, it definitely works. It can be tested in the same way I described in the prior posting. However, I tested it using www traffic (just to get a better idea of whether it really does anything).
....- Tomato has two preset rules for "www" on the "classification" page. They are "High" (for the first 512k traffic) and "Low" (for everything over 512k).
....- Just change Inbound "High" and "Low" on the Basic Settings page from "None" to 10%.
....- Visit a web page. It should be immediately obvious that the traffic slowed down.
So, by setting "Highest" to 100%, it will always get priority over any other traffic. The rest of the traffic won't be prioritized and will consume whatever's left (up to 100% if there's no MJ traffic).
My inbound speed is only 1500kbs. So, it wasn't hard for me to saturate my connection and determine MJ was getting priority. Using the simultaneous echo and speed tests, I saw my download speed drop by about 100kbs while speaking to the echo number.
The only thing I don't like about this is that you have to set the outbound and inbound limits conservatively. If your speed varies during the day (or your ISP gives "power boost") you'll never take advantage of it because you have to use the lowest speed you normally obtain. If you specify a higher speed, Tomato will send packets at that speed, and cause congestion (which, from what I've read, can eliminate the gains of using QoS).
That's where DD-WRT looks appealing. From what I've read, you can use TCP Vegas (a feature of the Linux kernal) to avoid congestion. People say using it alone is better than using QoS. Others say using it with QoS works well if the inbound/outbound limits are set to zero. Apparently DD-WRT allows zero, and will just prioritize packets, but not cap anything. The underlying TCP Vegas will control the flow of the entire pipe. (I haven't tried it yet. I'm just basing this on some things I've read.).
Mark | |
-
|
