rihad at mail.ru
Tue Dec 11 02:17:05 PST 2007
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?
More information about the freebsd-net