[ previous ] [ next ] [ threads ]
 From:  Manuel Kasper <mk at neon1 dot net>
 To:  Lee Sharp <leesharp at hal dash pc dot org>
 Cc:  "m0n0wall at lists dot m0n0 dot ch" <m0n0wall at lists dot m0n0 dot ch>
 Subject:  Re: [m0n0wall] The "buffer bloat" issue
 Date:  Sat, 8 Jan 2011 16:47:18 +0100
On 07.01.2011, at 20:05, Lee Sharp wrote:

> After reading this post on slashdot
(and the articles it referenced...  It took more than an hour) I started looking into it.  I am
having symptoms of this on my own office network, and adjusting the txqueuelen on my access points
has already shown improvement.  So I went looking in m0n0wall.  Uh...  FreeBSD ain't Linux. :)  So
what is our ring and buffer size?  I may not be able to fix "The" net, but I can fix "My" net!

Are you using the traffic shaper, or are any of your m0n0wall's network interfaces (or CPU)
sometimes near saturation? If not, then I think it's unlikely that adjusting queueing settings in
m0n0wall/FreeBSD will do much good. Queue/buffer sizes matter most where there is a bottleneck, but
the typical m0n0wall only has a couple of Ethernet interfaces where none have so much load that
packets would need to be queued for any significant time (in my experience anyway).

If using the traffic shaper (and thus artificially introducing a bottleneck), then the answer is
that the default queue size is 50 slots/packets, and it can be adjusted in the pipe configuration.

As a side thought - if you have a modem on m0n0wall's WAN port that uses excessively large buffers,
it may make sense to use the traffic shaper to limit upstream bandwidth to something slightly below
your actual speed, so that the queue will mostly be inside m0n0wall, where you can control it. OTOH,
since there is no flow control, this will not work at times when the WAN medium is congested (e.g.
for cable). And you're at the mercy of your ISP for the downstream anyway.

- Manuel