Pipe queues

[rihad]

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?