Date: Tue, 11 Dec 2007 11:11:51 -0800 From: Chuck Swiger <cswiger@mac.com> To: rihad <rihad@mail.ru> Cc: freebsd-net@freebsd.org Subject: Re: Pipe queues Message-ID: <EA06E0EA-C982-4A8B-9CAC-99AB35D4A4BC@mac.com> In-Reply-To: <475E3DB6.4030203@mail.ru> References: <475D6FD7.2000500@mail.ru> <DCFF3417-FC01-4F2C-ACA5-03CC0881DE59@mac.com> <475E3DB6.4030203@mail.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 10, 2007, at 11:35 PM, rihad wrote:
>> Pipes and queues are two different things; a pipe simulates a
>> network link, and a queue is used to hold packets which are
>> backlogged because they are arriving faster than the outbound link
>> (ie, a pipe) can transmit them.
> So you mean queues are only used on the sending side? (the box is
> acting as a router) and that their purpose is to diminish packet
> loss rate due to network congestion? Now I get it, thanks.
Queues are used to buffer packets before sending. For a router, this
affects traffic in both directions, but it's normally the case that
that Internet<->router link is slower than the router<->LAN link.
>>> What if I set it to 10000 slots, why should it wait to fill the
>>> queue before starting to send stuff out the network interface?
>> Well, it *doesn't* wait for the queue to be filled before starting
>> to send stuff out the network.
> This ipfw manpage section was the reason I asked (sorry for the
> formatting). What's with the "queuing delay" part? I'm totally
> confused.
>
> queue {slots | sizeKbytes}
> Queue size, in slots or KBytes. Default value is 50
> slots, which
> is the typical queue size for Ethernet devices. 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 inter-
> face with its 16KB packets.
The issue is that if you have a really slow upstream link, you can end
up queuing many seconds worth of traffic using the default queue
size-- depending on the priorities, you might have traffic being
buffers so long that it starts breaking connections or causing
needless TCP retries...
--
-Chuck
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EA06E0EA-C982-4A8B-9CAC-99AB35D4A4BC>