[LARTC] Has anybody used HTB?

[LARTC] Has anybody used HTB?

[eth]

    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/

Re: [LARTC] Has anybody used HTB?

[Martin Devera]

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/
> 
> 

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] Has anybody used HTB?

[eth]

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. :)

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] Has anybody used HTB?

[Martin Devera]

you can use one htb here like:

root (your full link, rateÎil%6k)
\
 ssh+icmp leaf (prio=0 ratePk ceil%6k)
 http leaf (prio=1 rate\x100k ceil%6k)
 other leaf (prio=2 rate\x100k ceil%6k)

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. :)
> 
> 
> 

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] Has anybody used HTB?

[eth]

Martin Devera wrote:

>you can use one htb here like:
>
>root (your full link, rateÎil%6k)
>\
> ssh+icmp leaf (prio=0 ratePk ceil%6k)
> http leaf (prio=1 rate\x100k ceil%6k)
> other leaf (prio=2 rate\x100k ceil%6k)
>
>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`676 ttl\x127 timeh2 usec
64 bytes from 192.168.1.64: icmp_seq`677 ttl\x127 timeh2 usec
64 bytes from 192.168.1.64: icmp_seq`678 ttl\x127 timeh5 usec
64 bytes from 192.168.1.64: icmp_seq`679 ttl\x127 timeh5 usec
64 bytes from 192.168.1.64: icmp_seq`680 ttl\x127 timeq3 usec
64 bytes from 192.168.1.64: icmp_seq`681 ttl\x127 timeh8 usec
64 bytes from 192.168.1.64: icmp_seq`682 ttl\x127 timef5 usec
64 bytes from 192.168.1.64: icmp_seq`683 ttl\x127 timee5 usec
64 bytes from 192.168.1.64: icmp_seq`684 ttl\x127 timeh8 usec
64 bytes from 192.168.1.64: icmp_seq`685 ttl\x127 timeg3 usec
64 bytes from 192.168.1.64: icmp_seq`686 ttl\x127 timeh9 usec
64 bytes from 192.168.1.64: icmp_seq`687 ttl\x127 timeq2 usec
64 bytes from 192.168.1.64: icmp_seq`688 ttl\x127 timeq4 usec
64 bytes from 192.168.1.64: icmp_seq`689 ttl\x127 time=1.410 msec
64 bytes from 192.168.1.64: icmp_seq`690 ttl\x127 timeq1 usec
64 bytes from 192.168.1.64: icmp_seq`691 ttl\x127 timei0 usec
64 bytes from 192.168.1.64: icmp_seq`692 ttl\x127 timeh7 usec
64 bytes from 192.168.1.64: icmp_seq`693 ttl\x127 timeh9 usec
64 bytes from 192.168.1.64: icmp_seq`694 ttl\x127 timeh9 usec
64 bytes from 192.168.1.64: icmp_seq`695 ttl\x127 timeq2 usec
64 bytes from 192.168.1.64: icmp_seq`696 ttl\x127 time=1.487 msec
64 bytes from 192.168.1.64: icmp_seq`697 ttl\x127 timeh5 usec
64 bytes from 192.168.1.64: icmp_seq`698 ttl\x127 timef9 usec
64 bytes from 192.168.1.64: icmp_seq`699 ttl\x127 timeh4 usec
64 bytes from 192.168.1.64: icmp_seq`700 ttl\x127 timeg6 usec
64 bytes from 192.168.1.64: icmp_seq`701 ttl\x127 timef0 usec
64 bytes from 192.168.1.64: icmp_seq`702 ttl\x127 timeq5 usec
64 bytes from 192.168.1.64: icmp_seq`703 ttl\x127 timeh8 usec
64 bytes from 192.168.1.64: icmp_seq`704 ttl\x127 timep2 usec
64 bytes from 192.168.1.64: icmp_seq`705 ttl\x127 timep5 usec   <--- 
 From now on I start and stop 4 ftp transfers
64 bytes from 192.168.1.64: icmp_seq`706 ttl\x127 time=1.554 msec
64 bytes from 192.168.1.64: icmp_seq`707 ttl\x127 timei0 usec
64 bytes from 192.168.1.64: icmp_seq`708 ttl\x127 time=4.287 msec
64 bytes from 192.168.1.64: icmp_seq`709 ttl\x127 time=1.491 msec
64 bytes from 192.168.1.64: icmp_seq`710 ttl\x127 time=3.105 msec
64 bytes from 192.168.1.64: icmp_seq`711 ttl\x127 timei0 usec
64 bytes from 192.168.1.64: icmp_seq`712 ttl\x127 time=1.461 msec
64 bytes from 192.168.1.64: icmp_seq`713 ttl\x127 timeh6 usec
64 bytes from 192.168.1.64: icmp_seq`714 ttl\x127 time=1.481 msec
64 bytes from 192.168.1.64: icmp_seq`715 ttl\x127 time=1.415 msec <-- I 
stop playing with ftp and let them flow
64 bytes from 192.168.1.64: icmp_seq`716 ttl\x127 time=1.295 msec
64 bytes from 192.168.1.64: icmp_seq`717 ttl\x127 timeq3 usec
64 bytes from 192.168.1.64: icmp_seq`718 ttl\x127 timeh8 usec
64 bytes from 192.168.1.64: icmp_seq`719 ttl\x127 timee2 usec
64 bytes from 192.168.1.64: icmp_seq`720 ttl\x127 time’1 usec
64 bytes from 192.168.1.64: icmp_seq`721 ttl\x127 time‚8 usec
64 bytes from 192.168.1.64: icmp_seq`722 ttl\x127 timeg1 usec
64 bytes from 192.168.1.64: icmp_seq`723 ttl\x127 timeh4 usec
64 bytes from 192.168.1.64: icmp_seq`724 ttl\x127 timeq6 usec
64 bytes from 192.168.1.64: icmp_seq`725 ttl\x127 timeq7 usec
64 bytes from 192.168.1.64: icmp_seq`726 ttl\x127 timeg0 usec
64 bytes from 192.168.1.64: icmp_seq`727 ttl\x127 timeh1 usec
64 bytes from 192.168.1.64: icmp_seq`728 ttl\x127 timei5 usec
64 bytes from 192.168.1.64: icmp_seq`729 ttl\x127 timeh0 usec
64 bytes from 192.168.1.64: icmp_seq`730 ttl\x127 time=1.416 msec
64 bytes from 192.168.1.64: icmp_seq`731 ttl\x127 timeq3 usec
64 bytes from 192.168.1.64: icmp_seq`732 ttl\x127 timei5 usec
64 bytes from 192.168.1.64: icmp_seq`733 ttl\x127 timei1 usec
64 bytes from 192.168.1.64: icmp_seq`734 ttl\x127 timeg5 usec
64 bytes from 192.168.1.64: icmp_seq`735 ttl\x127 timex2 usec
64 bytes from 192.168.1.64: icmp_seq`736 ttl\x127 timef2 usec
64 bytes from 192.168.1.64: icmp_seq`737 ttl\x127 timef0 usec
64 bytes from 192.168.1.64: icmp_seq`738 ttl\x127 timef2 usec
64 bytes from 192.168.1.64: icmp_seq`739 ttl\x127 timeq1 usec
64 bytes from 192.168.1.64: icmp_seq`740 ttl\x127 timeh4 usec
64 bytes from 192.168.1.64: icmp_seq`741 ttl\x127 timeh1 usec
64 bytes from 192.168.1.64: icmp_seq`742 ttl\x127 timeg5 usec
64 bytes from 192.168.1.64: icmp_seq`743 ttl\x127 timef9 usec
64 bytes from 192.168.1.64: icmp_seq`744 ttl\x127 timeg2 usec
64 bytes from 192.168.1.64: icmp_seq`745 ttl\x127 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!



_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] Has anybody used HTB?

[Martin Devera]

> 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`676 ttl\x127 timeh2 usec
> 64 bytes from 192.168.1.64: icmp_seq`677 ttl\x127 timeh2 usec
> 64 bytes from 192.168.1.64: icmp_seq`678 ttl\x127 timeh5 usec
> 64 bytes from 192.168.1.64: icmp_seq`679 ttl\x127 timeh5 usec
> 64 bytes from 192.168.1.64: icmp_seq`680 ttl\x127 timeq3 usec
> 64 bytes from 192.168.1.64: icmp_seq`681 ttl\x127 timeh8 usec
> 64 bytes from 192.168.1.64: icmp_seq`682 ttl\x127 timef5 usec
> 64 bytes from 192.168.1.64: icmp_seq`683 ttl\x127 timee5 usec
> 64 bytes from 192.168.1.64: icmp_seq`684 ttl\x127 timeh8 usec
> 64 bytes from 192.168.1.64: icmp_seq`685 ttl\x127 timeg3 usec
> 64 bytes from 192.168.1.64: icmp_seq`686 ttl\x127 timeh9 usec
> 64 bytes from 192.168.1.64: icmp_seq`687 ttl\x127 timeq2 usec
> 64 bytes from 192.168.1.64: icmp_seq`688 ttl\x127 timeq4 usec
> 64 bytes from 192.168.1.64: icmp_seq`689 ttl\x127 time=1.410 msec
> 64 bytes from 192.168.1.64: icmp_seq`690 ttl\x127 timeq1 usec
> 64 bytes from 192.168.1.64: icmp_seq`691 ttl\x127 timei0 usec
> 64 bytes from 192.168.1.64: icmp_seq`692 ttl\x127 timeh7 usec
> 64 bytes from 192.168.1.64: icmp_seq`693 ttl\x127 timeh9 usec
> 64 bytes from 192.168.1.64: icmp_seq`694 ttl\x127 timeh9 usec
> 64 bytes from 192.168.1.64: icmp_seq`695 ttl\x127 timeq2 usec
> 64 bytes from 192.168.1.64: icmp_seq`696 ttl\x127 time=1.487 msec
> 64 bytes from 192.168.1.64: icmp_seq`697 ttl\x127 timeh5 usec
> 64 bytes from 192.168.1.64: icmp_seq`698 ttl\x127 timef9 usec
> 64 bytes from 192.168.1.64: icmp_seq`699 ttl\x127 timeh4 usec
> 64 bytes from 192.168.1.64: icmp_seq`700 ttl\x127 timeg6 usec
> 64 bytes from 192.168.1.64: icmp_seq`701 ttl\x127 timef0 usec
> 64 bytes from 192.168.1.64: icmp_seq`702 ttl\x127 timeq5 usec
> 64 bytes from 192.168.1.64: icmp_seq`703 ttl\x127 timeh8 usec
> 64 bytes from 192.168.1.64: icmp_seq`704 ttl\x127 timep2 usec
> 64 bytes from 192.168.1.64: icmp_seq`705 ttl\x127 timep5 usec   <--- 
>  From now on I start and stop 4 ftp transfers
> 64 bytes from 192.168.1.64: icmp_seq`706 ttl\x127 time=1.554 msec
> 64 bytes from 192.168.1.64: icmp_seq`707 ttl\x127 timei0 usec
> 64 bytes from 192.168.1.64: icmp_seq`708 ttl\x127 time=4.287 msec
> 64 bytes from 192.168.1.64: icmp_seq`709 ttl\x127 time=1.491 msec
> 64 bytes from 192.168.1.64: icmp_seq`710 ttl\x127 time=3.105 msec
> 64 bytes from 192.168.1.64: icmp_seq`711 ttl\x127 timei0 usec
> 64 bytes from 192.168.1.64: icmp_seq`712 ttl\x127 time=1.461 msec
> 64 bytes from 192.168.1.64: icmp_seq`713 ttl\x127 timeh6 usec
> 64 bytes from 192.168.1.64: icmp_seq`714 ttl\x127 time=1.481 msec
> 64 bytes from 192.168.1.64: icmp_seq`715 ttl\x127 time=1.415 msec <-- I 
> stop playing with ftp and let them flow
> 64 bytes from 192.168.1.64: icmp_seq`716 ttl\x127 time=1.295 msec
> 64 bytes from 192.168.1.64: icmp_seq`717 ttl\x127 timeq3 usec
> 64 bytes from 192.168.1.64: icmp_seq`718 ttl\x127 timeh8 usec
> 64 bytes from 192.168.1.64: icmp_seq`719 ttl\x127 timee2 usec
> 64 bytes from 192.168.1.64: icmp_seq`720 ttl\x127 time’1 usec
> 64 bytes from 192.168.1.64: icmp_seq`721 ttl\x127 time‚8 usec
> 64 bytes from 192.168.1.64: icmp_seq`722 ttl\x127 timeg1 usec
> 64 bytes from 192.168.1.64: icmp_seq`723 ttl\x127 timeh4 usec
> 64 bytes from 192.168.1.64: icmp_seq`724 ttl\x127 timeq6 usec
> 64 bytes from 192.168.1.64: icmp_seq`725 ttl\x127 timeq7 usec
> 64 bytes from 192.168.1.64: icmp_seq`726 ttl\x127 timeg0 usec
> 64 bytes from 192.168.1.64: icmp_seq`727 ttl\x127 timeh1 usec
> 64 bytes from 192.168.1.64: icmp_seq`728 ttl\x127 timei5 usec
> 64 bytes from 192.168.1.64: icmp_seq`729 ttl\x127 timeh0 usec
> 64 bytes from 192.168.1.64: icmp_seq`730 ttl\x127 time=1.416 msec
> 64 bytes from 192.168.1.64: icmp_seq`731 ttl\x127 timeq3 usec
> 64 bytes from 192.168.1.64: icmp_seq`732 ttl\x127 timei5 usec
> 64 bytes from 192.168.1.64: icmp_seq`733 ttl\x127 timei1 usec
> 64 bytes from 192.168.1.64: icmp_seq`734 ttl\x127 timeg5 usec
> 64 bytes from 192.168.1.64: icmp_seq`735 ttl\x127 timex2 usec
> 64 bytes from 192.168.1.64: icmp_seq`736 ttl\x127 timef2 usec
> 64 bytes from 192.168.1.64: icmp_seq`737 ttl\x127 timef0 usec
> 64 bytes from 192.168.1.64: icmp_seq`738 ttl\x127 timef2 usec
> 64 bytes from 192.168.1.64: icmp_seq`739 ttl\x127 timeq1 usec
> 64 bytes from 192.168.1.64: icmp_seq`740 ttl\x127 timeh4 usec
> 64 bytes from 192.168.1.64: icmp_seq`741 ttl\x127 timeh1 usec
> 64 bytes from 192.168.1.64: icmp_seq`742 ttl\x127 timeg5 usec
> 64 bytes from 192.168.1.64: icmp_seq`743 ttl\x127 timef9 usec
> 64 bytes from 192.168.1.64: icmp_seq`744 ttl\x127 timeg2 usec
> 64 bytes from 192.168.1.64: icmp_seq`745 ttl\x127 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!
> 
> 
> 
> 
> 

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] Has anybody used HTB?

[eth]

<!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>

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/