Until now I''ve been using HTB instead of CBQ and it worked quite
good. I try now to prio ICMP and SSHwith the following:
tc_htb qdisc add dev eth1 root handle 1: htb default 10
# total
#78Kbytes
tc class add dev eth1 parent 1: classid 1:1 htb rate 76kbps ceil 78kbps
burst 2k
#50Kbytes
tc class add dev eth1 parent 1:1 classid 1:10 htb rate 48kbps ceil
76kbps burst 2k
#PRIO as qdisk for this slice
tc qdisc add dev eth1 parent 1:10 handle 100: prio
#I try to avoid a situation where a "massive" ping would disrupt
everything else
tc qdisc add dev eth1 parent 100:1 handle 101 tbf rate 8kbps
latency 1500ms burst 1540
#The second band (probably HTTP) shouldn''t eat everything from FTP
which should be tc filtered in band 3...
tc qdisc add dev eth1 parent 100:2 handle 102:1 htb default 100221
tc class add dev eth1 parent 102:1 classid 1002:1 htb rate 40kbps
ceil 76kbps burst 2k
... and the last line gives me an error: RTNETLINK answers: Invalid
argument. Why?
Your setup doesn''t make much sense. Two htbs can be done but there is no benefit. tc qdisc add dev eth1 parent 100:2 handle 102:1 is wrong because each qdisc handle takes form X:0 not X:1 ... devik On Wed, 6 Mar 2002, eth wrote:> Until now I''ve been using HTB instead of CBQ and it worked quite > good. I try now to prio ICMP and SSHwith the following: > > tc_htb qdisc add dev eth1 root handle 1: htb default 10 > > # total > #78Kbytes > tc class add dev eth1 parent 1: classid 1:1 htb rate 76kbps ceil 78kbps > burst 2k > > #50Kbytes > tc class add dev eth1 parent 1:1 classid 1:10 htb rate 48kbps ceil > 76kbps burst 2k > #PRIO as qdisk for this slice > tc qdisc add dev eth1 parent 1:10 handle 100: prio > #I try to avoid a situation where a "massive" ping would disrupt > everything else > tc qdisc add dev eth1 parent 100:1 handle 101 tbf rate 8kbps > latency 1500ms burst 1540 > #The second band (probably HTTP) shouldn''t eat everything from FTP > which should be tc filtered in band 3... > tc qdisc add dev eth1 parent 100:2 handle 102:1 htb default 100221 > > tc class add dev eth1 parent 102:1 classid 1002:1 htb rate 40kbps > ceil 76kbps burst 2k > > ... and the last line gives me an error: RTNETLINK answers: Invalid > argument. Why? > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > >
Martin Devera wrote:>Your setup doesn''t make much sense. Two htbs can be done >but there is no benefit. >Well... what I''m trying to do is to get a 50Kbytes/s slice in which ICMP and ssh should work perceptible faster than other and, below, http should work perceptible faster than the rest. I try to put the first htb for the 50K overall limit and then make PRIO as qdisc for the first htb. Each of the bands from this PRIO should have some form of limitting and I thought htb would do nice here to. In my view (everybody, please correct me if I''m wrong...) there should be some form of upper limit for the bands of PRIO so I can avoid the sittuation where e.g. 15 machines start to ping so the PRIO''s band 0 is always full and no other traffic works...>tc qdisc add dev eth1 parent 100:2 handle 102:1 is wrong >because each qdisc handle takes form X:0 not X:1 ... >devik >Thanks, I''ll try it. :)
you can use one htb here like: root (your full link, rate=ceil=256k) \ ssh+icmp leaf (prio=0 rate=50k ceil=256k) http leaf (prio=1 rate=100k ceil=256k) other leaf (prio=2 rate=100k ceil=256k) This is only example - I don''t remember correct numbers you want. In above ssh+icmp will go always first as long as they are under 50k, then http is priorized as long as it is in 100k limit .... devik On Wed, 6 Mar 2002, eth wrote:> Martin Devera wrote: > > >Your setup doesn''t make much sense. Two htbs can be done > >but there is no benefit. > > > Well... what I''m trying to do is to get a 50Kbytes/s slice in which ICMP > and ssh should work perceptible faster than other and, below, http > should work perceptible faster than the rest. I try to put the first htb > for the 50K overall limit and then make PRIO as qdisc for the first htb. > Each of the bands from this PRIO should have some form of limitting and > I thought htb would do nice here to. In my view (everybody, please > correct me if I''m wrong...) there should be some form of upper limit for > the bands of PRIO so I can avoid the sittuation where e.g. 15 machines > start to ping so the PRIO''s band 0 is always full and no other traffic > works... > > >tc qdisc add dev eth1 parent 100:2 handle 102:1 is wrong > >because each qdisc handle takes form X:0 not X:1 ... > >devik > > > Thanks, I''ll try it. :) > > >
Martin Devera wrote:>you can use one htb here like: > >root (your full link, rate=ceil=256k) >\ > ssh+icmp leaf (prio=0 rate=50k ceil=256k) > http leaf (prio=1 rate=100k ceil=256k) > other leaf (prio=2 rate=100k ceil=256k) > >This is only example - I don''t remember correct >numbers you want. In above ssh+icmp will go always >first as long as they are under 50k, then http >is priorized as long as it is in 100k limit .... >My first attempt was close to your example, like this: tc class add dev eth1 parent 1:0 classid 1:1 htb rate 626kbit ceil 628kbit burst 2k tc class add dev eth1 parent 1:1 classid 1:10 htb rate 388kbit ceil 400kbit burst 2k tc class add dev eth1 parent 1:10 classid 1:110 htb rate 32kbit ceil 32kbit burst 2k prio 1 tc qdisc add dev eth1 parent 1:110 handle 10:0 pfifo limit 10 tc class add dev eth1 parent 1:10 classid 1:120 htb rate 32kbit ceil 400kbit burst 2k prio 2 tc qdisc add dev eth1 parent 1:120 handle 12:0 sfq perturb 10 tc class add dev eth1 parent 1:10 classid 1:130 htb rate 112kbit ceil 400kbit burst 2k prio 3 tc qdisc add dev eth1 parent 1:130 handle 13:0 sfq perturb 10 I''ve tc-ed ICMP to be 1:110, ssh to be 1:120 and the rest 1:130. Guess what? Look at the following example, you can notice that although ICMP should be the highest prio, sometimes it''s not. Maybe I''ve made, again, some mistakes or maybe prio from HTB needs more tuning... :) 64 bytes from 192.168.1.64: icmp_seq=60676 ttl=127 time=682 usec 64 bytes from 192.168.1.64: icmp_seq=60677 ttl=127 time=682 usec 64 bytes from 192.168.1.64: icmp_seq=60678 ttl=127 time=685 usec 64 bytes from 192.168.1.64: icmp_seq=60679 ttl=127 time=685 usec 64 bytes from 192.168.1.64: icmp_seq=60680 ttl=127 time=713 usec 64 bytes from 192.168.1.64: icmp_seq=60681 ttl=127 time=688 usec 64 bytes from 192.168.1.64: icmp_seq=60682 ttl=127 time=665 usec 64 bytes from 192.168.1.64: icmp_seq=60683 ttl=127 time=655 usec 64 bytes from 192.168.1.64: icmp_seq=60684 ttl=127 time=688 usec 64 bytes from 192.168.1.64: icmp_seq=60685 ttl=127 time=673 usec 64 bytes from 192.168.1.64: icmp_seq=60686 ttl=127 time=689 usec 64 bytes from 192.168.1.64: icmp_seq=60687 ttl=127 time=712 usec 64 bytes from 192.168.1.64: icmp_seq=60688 ttl=127 time=714 usec 64 bytes from 192.168.1.64: icmp_seq=60689 ttl=127 time=1.410 msec 64 bytes from 192.168.1.64: icmp_seq=60690 ttl=127 time=711 usec 64 bytes from 192.168.1.64: icmp_seq=60691 ttl=127 time=690 usec 64 bytes from 192.168.1.64: icmp_seq=60692 ttl=127 time=687 usec 64 bytes from 192.168.1.64: icmp_seq=60693 ttl=127 time=689 usec 64 bytes from 192.168.1.64: icmp_seq=60694 ttl=127 time=689 usec 64 bytes from 192.168.1.64: icmp_seq=60695 ttl=127 time=712 usec 64 bytes from 192.168.1.64: icmp_seq=60696 ttl=127 time=1.487 msec 64 bytes from 192.168.1.64: icmp_seq=60697 ttl=127 time=685 usec 64 bytes from 192.168.1.64: icmp_seq=60698 ttl=127 time=669 usec 64 bytes from 192.168.1.64: icmp_seq=60699 ttl=127 time=684 usec 64 bytes from 192.168.1.64: icmp_seq=60700 ttl=127 time=676 usec 64 bytes from 192.168.1.64: icmp_seq=60701 ttl=127 time=660 usec 64 bytes from 192.168.1.64: icmp_seq=60702 ttl=127 time=715 usec 64 bytes from 192.168.1.64: icmp_seq=60703 ttl=127 time=688 usec 64 bytes from 192.168.1.64: icmp_seq=60704 ttl=127 time=702 usec 64 bytes from 192.168.1.64: icmp_seq=60705 ttl=127 time=705 usec <--- From now on I start and stop 4 ftp transfers 64 bytes from 192.168.1.64: icmp_seq=60706 ttl=127 time=1.554 msec 64 bytes from 192.168.1.64: icmp_seq=60707 ttl=127 time=690 usec 64 bytes from 192.168.1.64: icmp_seq=60708 ttl=127 time=4.287 msec 64 bytes from 192.168.1.64: icmp_seq=60709 ttl=127 time=1.491 msec 64 bytes from 192.168.1.64: icmp_seq=60710 ttl=127 time=3.105 msec 64 bytes from 192.168.1.64: icmp_seq=60711 ttl=127 time=690 usec 64 bytes from 192.168.1.64: icmp_seq=60712 ttl=127 time=1.461 msec 64 bytes from 192.168.1.64: icmp_seq=60713 ttl=127 time=686 usec 64 bytes from 192.168.1.64: icmp_seq=60714 ttl=127 time=1.481 msec 64 bytes from 192.168.1.64: icmp_seq=60715 ttl=127 time=1.415 msec <-- I stop playing with ftp and let them flow 64 bytes from 192.168.1.64: icmp_seq=60716 ttl=127 time=1.295 msec 64 bytes from 192.168.1.64: icmp_seq=60717 ttl=127 time=713 usec 64 bytes from 192.168.1.64: icmp_seq=60718 ttl=127 time=688 usec 64 bytes from 192.168.1.64: icmp_seq=60719 ttl=127 time=652 usec 64 bytes from 192.168.1.64: icmp_seq=60720 ttl=127 time=921 usec 64 bytes from 192.168.1.64: icmp_seq=60721 ttl=127 time=828 usec 64 bytes from 192.168.1.64: icmp_seq=60722 ttl=127 time=671 usec 64 bytes from 192.168.1.64: icmp_seq=60723 ttl=127 time=684 usec 64 bytes from 192.168.1.64: icmp_seq=60724 ttl=127 time=716 usec 64 bytes from 192.168.1.64: icmp_seq=60725 ttl=127 time=717 usec 64 bytes from 192.168.1.64: icmp_seq=60726 ttl=127 time=670 usec 64 bytes from 192.168.1.64: icmp_seq=60727 ttl=127 time=681 usec 64 bytes from 192.168.1.64: icmp_seq=60728 ttl=127 time=695 usec 64 bytes from 192.168.1.64: icmp_seq=60729 ttl=127 time=680 usec 64 bytes from 192.168.1.64: icmp_seq=60730 ttl=127 time=1.416 msec 64 bytes from 192.168.1.64: icmp_seq=60731 ttl=127 time=713 usec 64 bytes from 192.168.1.64: icmp_seq=60732 ttl=127 time=695 usec 64 bytes from 192.168.1.64: icmp_seq=60733 ttl=127 time=691 usec 64 bytes from 192.168.1.64: icmp_seq=60734 ttl=127 time=675 usec 64 bytes from 192.168.1.64: icmp_seq=60735 ttl=127 time=782 usec 64 bytes from 192.168.1.64: icmp_seq=60736 ttl=127 time=662 usec 64 bytes from 192.168.1.64: icmp_seq=60737 ttl=127 time=660 usec 64 bytes from 192.168.1.64: icmp_seq=60738 ttl=127 time=662 usec 64 bytes from 192.168.1.64: icmp_seq=60739 ttl=127 time=711 usec 64 bytes from 192.168.1.64: icmp_seq=60740 ttl=127 time=684 usec 64 bytes from 192.168.1.64: icmp_seq=60741 ttl=127 time=681 usec 64 bytes from 192.168.1.64: icmp_seq=60742 ttl=127 time=675 usec 64 bytes from 192.168.1.64: icmp_seq=60743 ttl=127 time=669 usec 64 bytes from 192.168.1.64: icmp_seq=60744 ttl=127 time=672 usec 64 bytes from 192.168.1.64: icmp_seq=60745 ttl=127 time=1.454 msec You can see that every once and then prio from HTB misses some prio as long as lower traffic is constant in terms of number of connections; I can testify too that the traffic to the shaped class is still smoth; HTB has some problems when starting and stopping connections, watch my notice above. The listing above made me attempt to make a htb root and from there a PRIO with it''s default 3 bands and each of then limited with HTBs... I quit after it looks like HTB doesn''t like being a leaf of a PRIO''s band. I''ve made the correction you suggested in the last mail but they were of no use. OTOH root HTB with PRIO and TBF on each leaf would make the band 0 *REALLY* prio, I''m sorry I don''t have the listing with ICMP''s you''ll have to take my word for it ;-). Still in the second case (PRIO+TBF) FTP on the lower bands was very poor distributed in terms of who gets what amount of traffic; plus it was exactly like I thought, if you start 10 pings you drown the other bands... dilema!
> I''ve tc-ed ICMP to be 1:110, ssh to be 1:120 and the rest 1:130. Guess > what? Look at the following example, you can notice that although ICMP > should be the highest prio, sometimes it''s not. Maybe I''ve made, again, > some mistakes or maybe prio from HTB needs more tuning... :)It is possible. On what hw you did the test ? 10Mbit eth ? If yes then there is possible to have approx 2ms jitter in delay because you can go in when large FTP packet is already in transit. You can try to do hierarchy of htb/prio/htb but from my side of view I''d rather repair htb''s priorization if there is bug ;) devik> 64 bytes from 192.168.1.64: icmp_seq=60676 ttl=127 time=682 usec > 64 bytes from 192.168.1.64: icmp_seq=60677 ttl=127 time=682 usec > 64 bytes from 192.168.1.64: icmp_seq=60678 ttl=127 time=685 usec > 64 bytes from 192.168.1.64: icmp_seq=60679 ttl=127 time=685 usec > 64 bytes from 192.168.1.64: icmp_seq=60680 ttl=127 time=713 usec > 64 bytes from 192.168.1.64: icmp_seq=60681 ttl=127 time=688 usec > 64 bytes from 192.168.1.64: icmp_seq=60682 ttl=127 time=665 usec > 64 bytes from 192.168.1.64: icmp_seq=60683 ttl=127 time=655 usec > 64 bytes from 192.168.1.64: icmp_seq=60684 ttl=127 time=688 usec > 64 bytes from 192.168.1.64: icmp_seq=60685 ttl=127 time=673 usec > 64 bytes from 192.168.1.64: icmp_seq=60686 ttl=127 time=689 usec > 64 bytes from 192.168.1.64: icmp_seq=60687 ttl=127 time=712 usec > 64 bytes from 192.168.1.64: icmp_seq=60688 ttl=127 time=714 usec > 64 bytes from 192.168.1.64: icmp_seq=60689 ttl=127 time=1.410 msec > 64 bytes from 192.168.1.64: icmp_seq=60690 ttl=127 time=711 usec > 64 bytes from 192.168.1.64: icmp_seq=60691 ttl=127 time=690 usec > 64 bytes from 192.168.1.64: icmp_seq=60692 ttl=127 time=687 usec > 64 bytes from 192.168.1.64: icmp_seq=60693 ttl=127 time=689 usec > 64 bytes from 192.168.1.64: icmp_seq=60694 ttl=127 time=689 usec > 64 bytes from 192.168.1.64: icmp_seq=60695 ttl=127 time=712 usec > 64 bytes from 192.168.1.64: icmp_seq=60696 ttl=127 time=1.487 msec > 64 bytes from 192.168.1.64: icmp_seq=60697 ttl=127 time=685 usec > 64 bytes from 192.168.1.64: icmp_seq=60698 ttl=127 time=669 usec > 64 bytes from 192.168.1.64: icmp_seq=60699 ttl=127 time=684 usec > 64 bytes from 192.168.1.64: icmp_seq=60700 ttl=127 time=676 usec > 64 bytes from 192.168.1.64: icmp_seq=60701 ttl=127 time=660 usec > 64 bytes from 192.168.1.64: icmp_seq=60702 ttl=127 time=715 usec > 64 bytes from 192.168.1.64: icmp_seq=60703 ttl=127 time=688 usec > 64 bytes from 192.168.1.64: icmp_seq=60704 ttl=127 time=702 usec > 64 bytes from 192.168.1.64: icmp_seq=60705 ttl=127 time=705 usec <--- > From now on I start and stop 4 ftp transfers > 64 bytes from 192.168.1.64: icmp_seq=60706 ttl=127 time=1.554 msec > 64 bytes from 192.168.1.64: icmp_seq=60707 ttl=127 time=690 usec > 64 bytes from 192.168.1.64: icmp_seq=60708 ttl=127 time=4.287 msec > 64 bytes from 192.168.1.64: icmp_seq=60709 ttl=127 time=1.491 msec > 64 bytes from 192.168.1.64: icmp_seq=60710 ttl=127 time=3.105 msec > 64 bytes from 192.168.1.64: icmp_seq=60711 ttl=127 time=690 usec > 64 bytes from 192.168.1.64: icmp_seq=60712 ttl=127 time=1.461 msec > 64 bytes from 192.168.1.64: icmp_seq=60713 ttl=127 time=686 usec > 64 bytes from 192.168.1.64: icmp_seq=60714 ttl=127 time=1.481 msec > 64 bytes from 192.168.1.64: icmp_seq=60715 ttl=127 time=1.415 msec <-- I > stop playing with ftp and let them flow > 64 bytes from 192.168.1.64: icmp_seq=60716 ttl=127 time=1.295 msec > 64 bytes from 192.168.1.64: icmp_seq=60717 ttl=127 time=713 usec > 64 bytes from 192.168.1.64: icmp_seq=60718 ttl=127 time=688 usec > 64 bytes from 192.168.1.64: icmp_seq=60719 ttl=127 time=652 usec > 64 bytes from 192.168.1.64: icmp_seq=60720 ttl=127 time=921 usec > 64 bytes from 192.168.1.64: icmp_seq=60721 ttl=127 time=828 usec > 64 bytes from 192.168.1.64: icmp_seq=60722 ttl=127 time=671 usec > 64 bytes from 192.168.1.64: icmp_seq=60723 ttl=127 time=684 usec > 64 bytes from 192.168.1.64: icmp_seq=60724 ttl=127 time=716 usec > 64 bytes from 192.168.1.64: icmp_seq=60725 ttl=127 time=717 usec > 64 bytes from 192.168.1.64: icmp_seq=60726 ttl=127 time=670 usec > 64 bytes from 192.168.1.64: icmp_seq=60727 ttl=127 time=681 usec > 64 bytes from 192.168.1.64: icmp_seq=60728 ttl=127 time=695 usec > 64 bytes from 192.168.1.64: icmp_seq=60729 ttl=127 time=680 usec > 64 bytes from 192.168.1.64: icmp_seq=60730 ttl=127 time=1.416 msec > 64 bytes from 192.168.1.64: icmp_seq=60731 ttl=127 time=713 usec > 64 bytes from 192.168.1.64: icmp_seq=60732 ttl=127 time=695 usec > 64 bytes from 192.168.1.64: icmp_seq=60733 ttl=127 time=691 usec > 64 bytes from 192.168.1.64: icmp_seq=60734 ttl=127 time=675 usec > 64 bytes from 192.168.1.64: icmp_seq=60735 ttl=127 time=782 usec > 64 bytes from 192.168.1.64: icmp_seq=60736 ttl=127 time=662 usec > 64 bytes from 192.168.1.64: icmp_seq=60737 ttl=127 time=660 usec > 64 bytes from 192.168.1.64: icmp_seq=60738 ttl=127 time=662 usec > 64 bytes from 192.168.1.64: icmp_seq=60739 ttl=127 time=711 usec > 64 bytes from 192.168.1.64: icmp_seq=60740 ttl=127 time=684 usec > 64 bytes from 192.168.1.64: icmp_seq=60741 ttl=127 time=681 usec > 64 bytes from 192.168.1.64: icmp_seq=60742 ttl=127 time=675 usec > 64 bytes from 192.168.1.64: icmp_seq=60743 ttl=127 time=669 usec > 64 bytes from 192.168.1.64: icmp_seq=60744 ttl=127 time=672 usec > 64 bytes from 192.168.1.64: icmp_seq=60745 ttl=127 time=1.454 msec > > > You can see that every once and then prio from HTB misses some prio > as long as lower traffic is constant in terms of number of connections; > I can testify too that the traffic to the shaped class is still smoth; > HTB has some problems when starting and stopping connections, watch my > notice above. The listing above made me attempt to make a htb root and > from there a PRIO with it''s default 3 bands and each of then limited > with HTBs... I quit after it looks like HTB doesn''t like being a leaf of > a PRIO''s band. I''ve made the correction you suggested in the last mail > but they were of no use. OTOH root HTB with PRIO and TBF on each leaf > would make the band 0 *REALLY* prio, I''m sorry I don''t have the listing > with ICMP''s you''ll have to take my word for it ;-). Still in the second > case (PRIO+TBF) FTP on the lower bands was very poor distributed in > terms of who gets what amount of traffic; plus it was exactly like I > thought, if you start 10 pings you drown the other bands... dilema! > > > > >
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title></title>
</head>
<body>
Martin Devera wrote:<br>
<blockquote type="cite"
cite="mid:Pine.LNX.4.10.10203081156510.15162-100000@luxik.cdi.cz">
<blockquote type="cite">
<pre wrap="">I''ve tc-ed ICMP to be 1:110, ssh to be
1:120 and the rest 1:130. Guess <br>what? Look at the following example,
you can notice that although ICMP <br>should be the highest prio,
sometimes it''s not. Maybe I''ve made, again, <br>some
mistakes or maybe prio from HTB needs more tuning... :)<br></pre>
</blockquote>
<pre wrap=""><!----><br>It is possible. On what
hw you did the test ? 10Mbit eth ? If yes then<br>there is possible to
have approx 2ms jitter in delay because you can<br>go in when large FTP
packet is already in transit.</pre>
</blockquote>
You guessed right, I was on 10Mbit ethernet. Then again, how did PRIO managed
to make it happen?<br>
<br>
Wait a second. Can''t we... I mean you... make a decision to stop
sending
the pending packet if something more important has just arrived? I guess
not... giving a seconf thought it''s like once the driver has
"spited" the
bytes in the NIC''s hardware buffer they''re gone for good...
unless there
is a standard in the kernel to say "Stop now nomatter what".<br>
<br>
If things are like you say the smaller the MTU the smaller the effect,
right?<br>
<blockquote type="cite"
cite="mid:Pine.LNX.4.10.10203081156510.15162-100000@luxik.cdi.cz">
<pre wrap="">You can try to do hierarchy of htb/prio/htb
but from my side of view<br>I''d rather repair htb''s
priorization if there is bug ;)<br></pre>
</blockquote>
Well... it''ll be nice to have an htb option with 0 to 9 with 0 being
the
most draconian in terms of prio and lousy in terms of bucketing and 9 the
oposite. But again I''m not in your''s shoes... ;-)<br>
<br>
</body>
</html>