From owner-freebsd-net@FreeBSD.ORG Tue Dec 11 10:17:04 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE05716A419 for ; Tue, 11 Dec 2007 10:17:04 +0000 (UTC) (envelope-from rihad@mail.ru) Received: from mx7.mail.ru (mx7.mail.ru [194.67.23.27]) by mx1.freebsd.org (Postfix) with ESMTP id B5EF713C442 for ; Tue, 11 Dec 2007 10:17:04 +0000 (UTC) (envelope-from rihad@mail.ru) Received: from [217.25.20.94] (port=35023 helo=[217.25.20.94]) by mx7.mail.ru with esmtp id 1J22Ag-0007Th-00; Tue, 11 Dec 2007 13:17:02 +0300 Message-ID: <475E6374.3070500@mail.ru> Date: Tue, 11 Dec 2007 14:16:20 +0400 From: rihad User-Agent: Icedove 1.5.0.14pre (X11/20071018) MIME-Version: 1.0 To: Peter Jeremy References: <475D6FD7.2000500@mail.ru> <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> In-Reply-To: <20071211093653.GN11310@server.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Pipe queues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2007 10:17:05 -0000 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?