From mboxrd@z Thu Jan 1 00:00:00 1970 From: Martin Devera Date: Fri, 08 Mar 2002 11:35:58 +0000 Subject: Re: [LARTC] Has anybody used HTB? Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable To: lartc@vger.kernel.org > I've tc-ed ICMP to be 1:110, ssh to be 1:120 and the rest 1:130. Guess=20 > what? Look at the following example, you can notice that although ICMP=20 > should be the highest prio, sometimes it's not. Maybe I've made, again,=20 > 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 =20 > 64 bytes from 192.168.1.64: icmp_seq`676 ttl=127 timeh2 usec > 64 bytes from 192.168.1.64: icmp_seq`677 ttl=127 timeh2 usec > 64 bytes from 192.168.1.64: icmp_seq`678 ttl=127 timeh5 usec > 64 bytes from 192.168.1.64: icmp_seq`679 ttl=127 timeh5 usec > 64 bytes from 192.168.1.64: icmp_seq`680 ttl=127 timeq3 usec > 64 bytes from 192.168.1.64: icmp_seq`681 ttl=127 timeh8 usec > 64 bytes from 192.168.1.64: icmp_seq`682 ttl=127 timef5 usec > 64 bytes from 192.168.1.64: icmp_seq`683 ttl=127 timee5 usec > 64 bytes from 192.168.1.64: icmp_seq`684 ttl=127 timeh8 usec > 64 bytes from 192.168.1.64: icmp_seq`685 ttl=127 timeg3 usec > 64 bytes from 192.168.1.64: icmp_seq`686 ttl=127 timeh9 usec > 64 bytes from 192.168.1.64: icmp_seq`687 ttl=127 timeq2 usec > 64 bytes from 192.168.1.64: icmp_seq`688 ttl=127 timeq4 usec > 64 bytes from 192.168.1.64: icmp_seq`689 ttl=127 time=3D1.410 msec > 64 bytes from 192.168.1.64: icmp_seq`690 ttl=127 timeq1 usec > 64 bytes from 192.168.1.64: icmp_seq`691 ttl=127 timei0 usec > 64 bytes from 192.168.1.64: icmp_seq`692 ttl=127 timeh7 usec > 64 bytes from 192.168.1.64: icmp_seq`693 ttl=127 timeh9 usec > 64 bytes from 192.168.1.64: icmp_seq`694 ttl=127 timeh9 usec > 64 bytes from 192.168.1.64: icmp_seq`695 ttl=127 timeq2 usec > 64 bytes from 192.168.1.64: icmp_seq`696 ttl=127 time=3D1.487 msec > 64 bytes from 192.168.1.64: icmp_seq`697 ttl=127 timeh5 usec > 64 bytes from 192.168.1.64: icmp_seq`698 ttl=127 timef9 usec > 64 bytes from 192.168.1.64: icmp_seq`699 ttl=127 timeh4 usec > 64 bytes from 192.168.1.64: icmp_seq`700 ttl=127 timeg6 usec > 64 bytes from 192.168.1.64: icmp_seq`701 ttl=127 timef0 usec > 64 bytes from 192.168.1.64: icmp_seq`702 ttl=127 timeq5 usec > 64 bytes from 192.168.1.64: icmp_seq`703 ttl=127 timeh8 usec > 64 bytes from 192.168.1.64: icmp_seq`704 ttl=127 timep2 usec > 64 bytes from 192.168.1.64: icmp_seq`705 ttl=127 timep5 usec <---=20 > From now on I start and stop 4 ftp transfers > 64 bytes from 192.168.1.64: icmp_seq`706 ttl=127 time=3D1.554 msec > 64 bytes from 192.168.1.64: icmp_seq`707 ttl=127 timei0 usec > 64 bytes from 192.168.1.64: icmp_seq`708 ttl=127 time=3D4.287 msec > 64 bytes from 192.168.1.64: icmp_seq`709 ttl=127 time=3D1.491 msec > 64 bytes from 192.168.1.64: icmp_seq`710 ttl=127 time=3D3.105 msec > 64 bytes from 192.168.1.64: icmp_seq`711 ttl=127 timei0 usec > 64 bytes from 192.168.1.64: icmp_seq`712 ttl=127 time=3D1.461 msec > 64 bytes from 192.168.1.64: icmp_seq`713 ttl=127 timeh6 usec > 64 bytes from 192.168.1.64: icmp_seq`714 ttl=127 time=3D1.481 msec > 64 bytes from 192.168.1.64: icmp_seq`715 ttl=127 time=3D1.415 msec <-- I = > stop playing with ftp and let them flow > 64 bytes from 192.168.1.64: icmp_seq`716 ttl=127 time=3D1.295 msec > 64 bytes from 192.168.1.64: icmp_seq`717 ttl=127 timeq3 usec > 64 bytes from 192.168.1.64: icmp_seq`718 ttl=127 timeh8 usec > 64 bytes from 192.168.1.64: icmp_seq`719 ttl=127 timee2 usec > 64 bytes from 192.168.1.64: icmp_seq`720 ttl=127 time=921 usec > 64 bytes from 192.168.1.64: icmp_seq`721 ttl=127 time=828 usec > 64 bytes from 192.168.1.64: icmp_seq`722 ttl=127 timeg1 usec > 64 bytes from 192.168.1.64: icmp_seq`723 ttl=127 timeh4 usec > 64 bytes from 192.168.1.64: icmp_seq`724 ttl=127 timeq6 usec > 64 bytes from 192.168.1.64: icmp_seq`725 ttl=127 timeq7 usec > 64 bytes from 192.168.1.64: icmp_seq`726 ttl=127 timeg0 usec > 64 bytes from 192.168.1.64: icmp_seq`727 ttl=127 timeh1 usec > 64 bytes from 192.168.1.64: icmp_seq`728 ttl=127 timei5 usec > 64 bytes from 192.168.1.64: icmp_seq`729 ttl=127 timeh0 usec > 64 bytes from 192.168.1.64: icmp_seq`730 ttl=127 time=3D1.416 msec > 64 bytes from 192.168.1.64: icmp_seq`731 ttl=127 timeq3 usec > 64 bytes from 192.168.1.64: icmp_seq`732 ttl=127 timei5 usec > 64 bytes from 192.168.1.64: icmp_seq`733 ttl=127 timei1 usec > 64 bytes from 192.168.1.64: icmp_seq`734 ttl=127 timeg5 usec > 64 bytes from 192.168.1.64: icmp_seq`735 ttl=127 timex2 usec > 64 bytes from 192.168.1.64: icmp_seq`736 ttl=127 timef2 usec > 64 bytes from 192.168.1.64: icmp_seq`737 ttl=127 timef0 usec > 64 bytes from 192.168.1.64: icmp_seq`738 ttl=127 timef2 usec > 64 bytes from 192.168.1.64: icmp_seq`739 ttl=127 timeq1 usec > 64 bytes from 192.168.1.64: icmp_seq`740 ttl=127 timeh4 usec > 64 bytes from 192.168.1.64: icmp_seq`741 ttl=127 timeh1 usec > 64 bytes from 192.168.1.64: icmp_seq`742 ttl=127 timeg5 usec > 64 bytes from 192.168.1.64: icmp_seq`743 ttl=127 timef9 usec > 64 bytes from 192.168.1.64: icmp_seq`744 ttl=127 timeg2 usec > 64 bytes from 192.168.1.64: icmp_seq`745 ttl=127 time=3D1.454 msec >=20 >=20 > You can see that every once and then prio from HTB misses some prio=20 > as long as lower traffic is constant in terms of number of connections;=20 > I can testify too that the traffic to the shaped class is still smoth;=20 > HTB has some problems when starting and stopping connections, watch my=20 > notice above. The listing above made me attempt to make a htb root and=20 > from there a PRIO with it's default 3 bands and each of then limited=20 > 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=20 > but they were of no use. OTOH root HTB with PRIO and TBF on each leaf=20 > would make the band 0 *REALLY* prio, I'm sorry I don't have the listing=20 > with ICMP's you'll have to take my word for it ;-). Still in the second=20 > case (PRIO+TBF) FTP on the lower bands was very poor distributed in=20 > terms of who gets what amount of traffic; plus it was exactly like I=20 > thought, if you start 10 pings you drown the other bands... dilema! >=20 >=20 >=20 >=20 >=20 _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/