From owner-freebsd-net@FreeBSD.ORG Tue Nov 3 04:32:20 2009 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 3E09E1065694 for ; Tue, 3 Nov 2009 04:32:20 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [62.231.161.221]) by mx1.freebsd.org (Postfix) with ESMTP id 7FF088FC17 for ; Tue, 3 Nov 2009 04:32:19 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.3/8.14.3) with ESMTP id nA347Asm073400; Tue, 3 Nov 2009 11:07:10 +0700 (KRAT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4AEFAC6E.5080805@rdtc.ru> Date: Tue, 03 Nov 2009 11:07:10 +0700 From: Eugene Grosbein User-Agent: Thunderbird 2.0.0.23 (X11/20090918) MIME-Version: 1.0 To: Barney Cordoba References: <274298.85978.qm@web63908.mail.re1.yahoo.com> In-Reply-To: <274298.85978.qm@web63908.mail.re1.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, rihad Subject: Re: dummynet dropping too many packets 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, 03 Nov 2009 04:32:20 -0000 Barney Cordoba wrote: > Your problem is that at high traffic levels you need to reduce traffic > flows, not just delay it as dummynet does. Dummynet does not "just adds delay". > The entire point of traffic > shaping is to smooth out your traffic flows; not to make it so choppy > that you have packets sitting in a transmit queue for 1/2 millisecond > in addition to the dummynet delays. While dummynet may not be dropping > packets, you have packets being dropped in TCP stacks throughout your > customer base, most likely. If you followed the thread, you known that rihad tried GRED. The problem was not due to exceeded bandwidth but in inadequate interface-level FIFO queue length. And no way to adjust it without a patch. This makes me think we should have general user interface for setting the queue length for any network interface just like Cisco 'hold-queue' command does. For now, only some drivers (e.g., em(4)) have such option.