Hello all, Thank you for the help so far. After updating iproute2 package, now my Centos 4.4 seems to be able to run TC from shorewall. I use DSL 64kbps/384kbps for up and downstream speed. I connect to DSL modem through eth0 (192.168.0.200/24). I follow the example from the shorewall TC guide for ppp0. http://www.shorewall.net/traffic_shaping.htm The problem is, it seems that TC is not working on eth0. No matter how small I set it, the download speed is always in full speed. However, when I test it on eth1, it seems to work. The download speed is limited to what I set in tcclasses and tcrules. So, I''m not really sure. Based on the example for using ppp0, my setup should be on eth0 too, right? Since it''s the interface that connected to the internet. But, based on the testing, the one that is working for TC is eth1. What is the correct answer? This is my setup: tcdevices: #INTERFACE IN-BANDWITH OUT-BANDWIDTH eth1 384kbps 64kbps tcclasses: #INTERFACE MARK RATE CEIL PRIORITY OPTIONS eth1 1 full full 1 tcp-ack,tos-minimize-delay eth1 2 5kbps 7kbps 2 eth1 3 5kbps 7kbps 3 default tcrules: #MARK SOURCE DEST PROTO DEST SOURCE USER TEST LENGTH TOS # PORT(S) PORT(S) 1:F 0.0.0.0/0 0.0.0.0/0 icmp echo-request 1:F 0.0.0.0/0 0.0.0.0/0 icmp echo-reply 2:F 10.0.0.1/24 0.0.0.0/0 all (my notebook IP) 1:F 10.0.0.4/24 0.0.0.0/0 all Thank you very much, -- Fajar Priyanto | Reg''d Linux User #327841 | Linux tutorial http://linux2.arinet.org 9:34am up 21:25, 2.6.18.2-34-default GNU/Linux Let''s use OpenOffice. http://www.openoffice.org ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
On Sun, May 06, 2007 at 09:47:19AM +0700, Fajar Priyanto wrote:> The problem is, it seems that TC is not working on eth0. No matter how small I > set it, the download speed is always in full speed.> So, I''m not really sure. Based on the example for using ppp0, my setup should > be on eth0 too, right? Since it''s the interface that connected to the > internet. But, based on the testing, the one that is working for TC is eth1. > What is the correct answer?Without studying your configuration, my bet is that you''ve got traffic shaping and policing mixed up. You have very little control over *download* speed, because that''s the policing direction. Traffic shaping, as a general concept, only really works for outbound traffic - policing is something of a hack, with fairly limited effect. Measuring your download speed is unlikely to be what you should be doing. (I''m not awake enough to figure out your specific problem, maybe this gives you a hint as to what''s wrong) ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
Fajar Priyanto wrote:>I use DSL 64kbps/384kbps for up and downstream speed. I connect to DSL modem >through eth0 (192.168.0.200/24). I follow the example from the shorewall TC >guide for ppp0. http://www.shorewall.net/traffic_shaping.htm > >The problem is, it seems that TC is not working on eth0. No matter how small I >set it, the download speed is always in full speed. > >However, when I test it on eth1, it seems to work. The download speed is >limited to what I set in tcclasses and tcrules. > >So, I''m not really sure. Based on the example for using ppp0, my setup should >be on eth0 too, right? Since it''s the interface that connected to the >internet. But, based on the testing, the one that is working for TC is eth1. >What is the correct answer? > >This is my setup: >tcdevices: >#INTERFACE IN-BANDWITH OUT-BANDWIDTH >eth1 384kbps 64kbps > >tcclasses: >#INTERFACE MARK RATE CEIL PRIORITY OPTIONS >eth1 1 full full 1 >tcp-ack,tos-minimize-delay >eth1 2 5kbps 7kbps 2 >eth1 3 5kbps 7kbps 3 default > >tcrules: >#MARK SOURCE DEST PROTO DEST SOURCE USER >TEST >LENGTH TOS ># PORT(S) PORT(S) >1:F 0.0.0.0/0 0.0.0.0/0 icmp echo-request >1:F 0.0.0.0/0 0.0.0.0/0 icmp echo-reply >2:F 10.0.0.1/24 0.0.0.0/0 all (my notebook IP) >1:F 10.0.0.4/24 0.0.0.0/0 allThat looks about right except that, as you ask, it SHOULD be eth0. But note that with those values, you are unlikely to see any difference. To expand upon Andrews reply, the traffic shaping only applies to the upstream (ie outbound) direction - I suggest reading (if you haven''t already) the following pages : http://lartc.org/howto/lartc.cookbook.ultimate-tc.html http://lartc.org/wondershaper/ where you will find an explanation of what it does, why, and how it works. What the traffic shaping part of this does is control your outbound traffic - it has (almost) no effect on downloads, and if you think about it, there is not much you can do AFTER packets have arrived. The policing side (set by the IN-BANDWIDTH value) does nothing more than drop excess packets AFTER they arrive. In TCP streams this results in retransmissions and the devices at each end of the connection should see this as evidence of congestion and reduce the rate at which data is sent. To be able to work, both your upstream and downstream bandwidth values MUST be less than actually supported on your line. This is so that the bottleneck becomes your firewall instead of the DSL line. The actual throughput available on most DSL lines is less than the ''nominal'' capacity stated for a number of reasons - so you will have to determine what those real rates are as described in the LARTC howto. Essentially, disable the prioritisation of ICMP Ping traffic (it skews the results), and sent both in and out bandwidth to less than your line rate. While performing a large download from a site with good bandwidth, adjust the IN rate upwards until you see ping times increase. This is the point where the inbound traffic rate is more than the line rate and the upstream router buffers are building up. NOW BACK OFF YOUR BANDWIDTH LIMIT a bit until the ping times drop again. Repeat this while doing a large upload and adjust your outbound bandwidth value. If you learn a few TC commands, you can make these adjustments ''on the fly'' without having to restart Shorewall each time. You will find that the operation of Wondershaper is virtually transparent, you just see (almost) full bandwidth AND low latency. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
On Sunday 06 May 2007 16:21, Simon Hobson wrote:> That looks about right except that, as you ask, it SHOULD be eth0. > But note that with those values, you are unlikely to see any > difference.That is the setup after I decided to test it on eth1.> To expand upon Andrews reply, the traffic shaping only applies to the > upstream (ie outbound) direction - I suggest reading (if you haven''t > already) the following pages :This is the part that I''m not sure I understand it correctly yet. Please bear with me. So, the DSL is 64kbps/384kbps connected to eth0 of my gateway. So, when I apply TC on eth0, does it mean that the TC only works on the 64kbps (upstream)? This is what I don''t understand. As far as I know it, say, when browsing the internet, the upstream data from the user is VERY small right? I mean, when we "click" on a download hyperlink on a website, the amount of data transmitted from that "click" is VERY small right? So, how come TC can save bandwidth by limiting the upstream data to the internet when the data is so small, and the resulting of those clicks are a very large data from the downloaded file then come in to eth0 from the internet. Sorry, if I''m mistaken it. Is it correct? What I get all this time is, the upstream from eth0 is the traffic from eth0 to eth1. So, eth0 can accept downstream traffic from the internet in 384kbps, and then "forward/upstreaming" the traffic to eth1 in 64kbps.> http://lartc.org/howto/lartc.cookbook.ultimate-tc.html > http://lartc.org/wondershapeWonderful docs. I''ll study it again several times. Thank you, -- Fajar Priyanto | Reg''d Linux User #327841 | Linux tutorial http://linux2.arinet.org 8:47pm up 0:14, 2.6.18.2-34-default GNU/Linux Let''s use OpenOffice. http://www.openoffice.org ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
Fajar Priyanto wrote:> > To expand upon Andrews reply, the traffic shaping only applies to the >> upstream (ie outbound) direction - I suggest reading (if you haven''t >> already) the following pages : > >This is the part that I''m not sure I understand it correctly yet. Please bear >with me. So, the DSL is 64kbps/384kbps connected to eth0 of my gateway. >So, when I apply TC on eth0, does it mean that the TC only works on the 64kbps >(upstream)?Yes>This is what I don''t understand. As far as I know it, say, when >browsing the internet, the upstream data from the user is VERY small right? I >mean, when we "click" on a download hyperlink on a website, the amount of >data transmitted from that "click" is VERY small right? So, how come TC can >save bandwidth by limiting the upstream data to the internet when the data is >so small, and the resulting of those clicks are a very large data from the >downloaded file then come in to eth0 from the internet. Sorry, if I''m >mistaken it. Is it correct?TC doesn''t actually save bandwidth - it controls how much you use and what gets ''first go'' at what is available. What you write is largely correct, but if you are doing other things like sending a large email, sharing files via p2p software etc, the traffic shaping will make sure that things like TCP ACKs and anything else you prioritise are sent ahead of the much larger packets. In addition - and this is VERY important - it limits the outbound traffic to slightly less than the DSL line actually supports so that you cannot build up a queue in your DSL modem/router. Without the traffic shaping, if you upload something large, then you will build a big queue of packets in your DSL modem or router. As you download, packets of data coming in need acknowledging to the sender - but if you have a large queue these acknowledgement packets will be delayed because of the larger packets ahead in the queue and this slows down the download. So what you want to do with your traffic shaping is select small but important traffic (TCP ACKs are a prime example, VoIP traffic would be another) and prioritise them. Similarly, select large but time insensitive traffic (such as the outboound side of p2p, outbound email, etc) and set them to a lower priority. That way, when you click a link, the packet containing that request won''t get stuck behind a big queue and delay the reception at the web server. At 64kbps you are able to send a max of 8kbyte/s. If you router/modem has just 8k of buffer then that''s a whole seconds worth of queuing time, a 16k buffer would represent a 2s queue. It''s not hard to see how that will impact the responsiveness you see as a user. Similarly, without the policing (limiting the INBOUND traffic on eth0), if you are running a large download then the buffers in the router sending data at the other end of your DSL line will fill up. Hence by dropping packets and triggering the sender(s) of the traffic to detect congestion and slow down, you can reduce the latency. That is (mostly) what this is about - minimising latency. But with inbound traffic, you cannot control what is sent (that is down to the router at the other end), so the best you can do is to drop packets and have the remote parties deterct this as congestion. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
On Sun, May 06, 2007 at 05:32:37PM +0100, Simon Hobson wrote:> But with inbound traffic, you cannot control what is sent (that is > down to the router at the other end), so the best you can do is to > drop packets and have the remote parties deterct this as congestion.The *best* you can do is to get your ISP to run traffic shaping as well, on their end of the link. Policing is a hack for when this is unavailable. (Good ISPs already do this. Really good ISPs will adjust the shaping rules at your request) ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/