Date: Fri, 23 May 2003 17:05:18 +0200 From: jeremie le-hen <le-hen_j@epita.fr> To: Michael Sierchio <kudzu@tenebras.com> Cc: ipfw@freebsd.org Subject: Re: Understanding queue size Message-ID: <20030523150517.GC24992@carpediem.epita.fr> In-Reply-To: <3ECE2D09.70609@tenebras.com> References: <20030523105030.GA24992@carpediem.epita.fr> <3ECE21BD.7060308@tenebras.com> <20030523140140.GB24992@carpediem.epita.fr> <3ECE2D09.70609@tenebras.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Ah, you're adjusting the camel from the wrong end. ;-) > > It's not queue size you want to adjust. If you want to reduce > delays for interactive traffic (telnet? ssh? etc.) assign that > traffic to a different queue, and all the queues to the same pipe. > Then you get the promised "worst case weighted fair queueing" In fact, I already have some queues in order to improve delays for interactive traffic. Here they are: pipe 1 config bw 125Kbit/s queue 76KBytes queue 10 config weight 100 pipe 1 mask all queue 20 config weight 100 pipe 1 queue 30 config weight 50 pipe 1 queue 40 config weight 1 pipe 1 # IRC, FTP, ICQ add queue 10 tcp from any to any 6667,5190,21 out via tun0 # SSH small packets (not file transfert via scp) add queue 10 tcp from any to any 22 iplen 1-1000 out via tun0 add queue 10 tcp from any 22 to any iplen 1-1000 out via tun0 # small ICMP, DNS requests and identd replies add queue 10 icmp from any to any iplen 1-200 out via tun0 add queue 10 udp from any to any 53 out via tun0 add queue 10 tcp from any 113 to any out via tun0 # TCP small packets (including SYNs, ACKs) add queue 20 tcp from any to any iplen 1-60 out via tun0 # SSH big packets (scp / rsync) add queue 40 tcp from any to any 22 iplen 1001-1500 out via tun0 add queue 40 tcp from any 22 to any iplen 1001-1500 out via tun0 # everything else add queue 30 tcp from any to any out via tun0 This just works fine, compared to when I didn't have any traffic shapping enabled. But I wanted to improve the responsivness of interactive traffic more and more, so I got concerned with queue size for the main pipe. > Once you've done this, then you might consider decreasing the > queue size on the interactive traffic. If it's full, it will > get priority. I'd think in terms of numbers of packets rather > than octets, probably... I hadn't understood I had to play with queue size for each queues, and not with the one of the main pipe. But that's the key ! :) Does reducing or increasing queue size of the main pipe have any relevance ? Finally, I should reduce size of interactive traffic queues, and increase size of the others. But how much ? Regards, -- Jeremie aka TtZ/TataZ jeremie.le-hen@epita.fr
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030523150517.GC24992>