What is your QoS settings for Inbound Limit?

I'm a little confused as to how inbound works, since it doesn't have it's own set of classifications... and I can't watch whats happening since the graphs only show outbound traffic.

My request is simple: When BitTorrent or another service is maxing out my inbound bandwidth, I'd like to be able to browse the web with little or no lag. I understand that inbound QoS drops packets which isn't the best way of handling this issue, but I'd still like to give it a shot.

The whole "inbound" Qos is confusing... If the only way to slow inbound transmisssion to a certain destination is to drop packets then so be it. The way I understand Tomato's "inbound" Qos is that you give it a maximum Inbound bandwidth and then it will give each classification the bandwidth up to the assigned limit. In other words if you have a 1000 kbps download and you give "medium" 80% then any connection assigned "medium" will get up to 800 kbps, and beyond that Tomato will start to drop packets. This being said, Tomato doesn't give you any place to classify inbound traffic. I would love to be able to set downloads over 1MB to a classification such as low and limit the download to this connection to something that wouldn't saturate my download and mess up my VoIP. Also, I agree, it would be cool to have graphs of inbound Qos as well as outbound. Just add it to my wish list!

No, I'm pretty sure it will cap it no matter what the other bandwidth consumption is (or another way to put it is that the particular "classification" is not allowed any more bandwidth than specified but it can have less)... See here.

I set my inbound bandwidth to 90% (14000kbit) and I set inbound "Lowest" class to 90%, just to give my web browsing/email some breathing room. I'll post back to see how it goes.

Click to expand...

Which the way I understand it is if you have torrents classified to lowest, they shouldn't use more than 90% of your bandwidth leaving at least 10% (or more since you didn't give it your total inbound bandwidth limit and I'm assuming you're leaving the other settings as "none") for all other classifications. Just remember that classifications are based on outbound connections not inbound. Again, it would be nice if you could "classify" based on inbound connections in addition to outbound, which would make this so much easier!

I dont use tomato so i cant speak specifically for the setting at hand, but i do know QoS and networking very well. QoS is packet classification that takes place on a network, minimally between 2 devices but is usually implemented on a much wider scale. Since none of us can specify packet classification in a way the isp will listen to, effectively we cannot have inbound QoS.

Now as stated if Tomato is selectively dropping packets or sending Tcp resets to help limit what gets through, that is one ingenious way to try to handle traffic but the problem is its still using processor cycles and can still ultimately lead too to many packets arriving at the wan interface at the same time. However I am curious though how that works out for you so please do post when you have an answer.

I tried setting "Lowest" class as 90, 95, 99, and even 100% and they all are capping my bittorrent traffic at ~300KBps

If I set it back to "none" the traffic begins to consume 1MB/s or more

It's not working very well This seems simple to me, so why is Tomato having a hard time? Even programs like uTorrent and NetLimiter can limit download bandwidth. Also, CPU usage goes up a bit when setting outbound QoS.

Sauce, run a few speed test at dsl reports and use those values to establish your 90% points to put into Tomato. I have tested BT quite a lot, an find that Tomato regulates inbound speeds to exactly what I have the category set for. It takes 12 - 15 seconds for Tomato to adjust an existing stream. The micro-torrent bandwidth chart shows the identical speeds that Tomato reports in it's realtime bandwidth monitor. Reducing BT to 50% or less of your available total download capacity should clear up your performance problems. Keep the upload for the torrent class to no more than 20% of the total up speed capacity. I don't care whether Tomato drops packets or delays return ACK to regulate in bound speeds. Whatever it is works perfectly for me, and results in nice smoothe web browsing and bandwidth for other applications. The inbound limits are a hard cap that will not allow consumption of un-used bandwidth.

hi, didnt want to start a new thread as this kind of deals with my issue.

Just want to know, If i have my mac set to a higher priority than another network users mac in the classification table, will BOTH inbound and outbound traffic to and from my mac address be prioritised. I know outbound definitly is, just theres no way for me to really check if inbound is being controlled on priority in the class list.

Also, i know the router has to rely on dropping packets, but is there no way for the router to, upon sending out (outbound) request for data, for it to 'set a limit' the rate its brought back to the router. Surely this is how programs like torrent clients limit their download speed (by limiting the speed, you do notice improvement in other apps). If these clients relied on dropping packets only, then the d/l bandwidth would still get saturated by the torrent traffic, that traffic only then to be dropped to the desired speed in the client, and therefore limiting it in the client (or NetLimiter) would not improve bandwith/speed for other apps, but it does. (sorry if that doesnt make much sense)

I don't know how inbound shaping works, but one of my housemates would download from nntp everynight and it'd hit about 1200KB/s and then bog down the internet. By limiting nntp, I was able to rescue the internet for other connections, so it does indeed do something.

I don't know how inbound shaping works, but one of my housemates would download from nntp everynight and it'd hit about 1200KB/s and then bog down the internet. By limiting nntp, I was able to rescue the internet for other connections, so it does indeed do something.

Click to expand...

Yeah ive noticed the same kind of thing, so im guessing its doing more than just dropping packets, as the bandwidth does free up for other things when one is limited.