Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 11 Dec 2007 14:16:20 +0400
From:      rihad <rihad@mail.ru>
To:        Peter Jeremy <peterjeremy@optushome.com.au>
Cc:        freebsd-net@freebsd.org
Subject:   Re: Pipe queues
Message-ID:  <475E6374.3070500@mail.ru>
In-Reply-To: <20071211093653.GN11310@server.vk2pj.dyndns.org>
References:  <475D6FD7.2000500@mail.ru> <DCFF3417-FC01-4F2C-ACA5-03CC0881DE59@mac.com> <20071210120353.B40679@xorpc.icir.org> <475DA624.4010104@seclark.us> <475E1E4D.4090409@mail.ru> <20071211074353.GI11310@server.vk2pj.dyndns.org> <475E4AC4.4030903@mail.ru> <20071211093653.GN11310@server.vk2pj.dyndns.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Peter Jeremy wrote:
> On Tue, Dec 11, 2007 at 12:31:00PM +0400, rihad wrote:
>> Peter Jeremy wrote:
>>> On Tue, Dec 11, 2007 at 09:21:17AM +0400, rihad wrote:
>>>> And if I _only_ want to shape IP traffic to given speed, without 
>>>> prioritizing anything, do I still need queues? This was the whole point.
>>> No you don't.  I'm using pipes without queues extensively to simulate
>>> WANs without bothering with any prioritisation.
>> Great! One fine point remains, though:
>> # ipfw pipe 1 config bw 128Kbit/s
>> will use a queue of 50 slots by default. What good are they for, if I 
>> didn't ask for queuing in the first place?
> 
> 'queue' is used in two distinct ways within the ipfw/dummynet code:
> 1) There's a "queue" object created with 'ipfw queue NNN config ...'
>    This is used to support WF2Q+ to allow a fixed bandwidth to be
>    unevenly shared between different traffic types.
> 2) There is a "queue" option on the "pipe" object that defines a FIFO
>    associated with the pipe.
> 
> I had assumed you were talking about the former (and my response was
> related to this) but given your latest posting, and having re-read the
> thread, I suspect I may have been wrong.  Whilst I don't use queue
> objects, I do use the queue option on my pipes.
> 
Yup, I'm only setting up traffic speed limits.

> In your example, you have a pipe that can handle 128kbps (16kBps).  If
> you write a 1600byte packet to it, then the packet will reappear
> 100msec later.  Any further packets written to that pipe during that
> time will be dropped if they can't be placed on a queue.  The
> practical throughput depends on the number of queue slots available
> and the number of writers.  I suggest you do some reading on queueing
> theory for the gory details.
> 
You've just explained this quite clearly. It follows that pipe queues 
are only used as a last line of defense before having to drop the 
packet. All fine so far. The reason of my OP was primarily this excerpt 
from man ipfw which I seem to be misinterpreting:

Note that for slow speed links you should keep the queue size short or 
your traffic might be affected by a significant queueing delay.  E.g., 
50 max-sized ethernet packets (1500 bytes) mean 600Kbit or 20s of queue 
on a 30Kbit/s pipe.  Even worse effects can result if you get packets 
from an interface with a much larger MTU, e.g. the loopback interface 
with its 16KB packets.

Does it look like they were talking of item 1) or 2) as you explained? 
As I only care of bandwidth limitation, and not of any packet 
prioritizing, should I be concerned with what they're saying? How on 
earth could increasing queue size limit actual throughput? Isn't the 
manpage saying that if I give a 128Kbit pipe an unnecessarily large 
queue (say, 160Kbyte - 10 seconds worth of data) clients will have to 
wait for 10 seconds before starting to get any data?



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?475E6374.3070500>