Skip site navigation (1)Skip section navigation (2)
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>