|
||||||||||
On 07.01.2011, at 20:05, Lee Sharp wrote: > After reading this post on slashdot http://tech.slashdot.org/story/11/01/07/0533226/Bufferbloat-mdash-the-Submarine-Thats-Sinking-the-Net (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 |