[ previous ] [ next ] [ threads ]
 From:  Lee Sharp <leesharp at hal dash pc dot org>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] The "buffer bloat" issue
 Date:  Sat, 08 Jan 2011 13:24:37 -0500
On 01/08/2011 10:47 AM, Manuel Kasper wrote:
> 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.

Cool.  For the record, I was not seeing any problems with m0n0wall.  I 
just wanted to know what the behavior was.  The fact that the traffic 
shaper has a 50 packet queue length was something I should have noticed. 
:)  However, the traffic shaper does not come into play on any internal 
traffic (LAN to Opt1 for example) correct?  What is the queue length there?