From owner-freebsd-pf@FreeBSD.ORG Wed Jul 6 16:50:22 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B85131065687 for ; Wed, 6 Jul 2011 16:50:22 +0000 (UTC) (envelope-from peter@bsdly.net) Received: from skapet.bsdly.net (cl-426.sto-01.se.sixxs.net [IPv6:2001:16d8:ff00:1a9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 731FF8FC12 for ; Wed, 6 Jul 2011 16:50:22 +0000 (UTC) Received: from [10.168.103.30] (helo=deeperthought.bsdly.net.bsdly.net ident=peter) by skapet.bsdly.net with esmtp (Exim 4.76) (envelope-from ) id 1QeVIr-0007wC-0K; Wed, 06 Jul 2011 18:50:21 +0200 From: peter@bsdly.net (Peter N. M. Hansteen) To: Calomel Org References: <20110706152506.GA26334@calomel.org> Date: Wed, 06 Jul 2011 18:50:18 +0200 In-Reply-To: <20110706152506.GA26334@calomel.org> (Calomel Org's message of "Wed, 6 Jul 2011 11:25:06 -0400") Message-ID: <877h7vcq0l.fsf@deeperthought.bsdly.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: misc@openbsd.org, freebsd-pf@freebsd.org Subject: Re: pf ALTQ bandwidth limited to a 32bit value (4294Mb) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 16:50:22 -0000 Calomel Org writes: > ALTQ using hfsc is limited to a maximum parent bandwidth of 4294Mb. > This value is 2^32 or 4,294,967,296 bits. If you set the bandwidth any > higher, altq will flip back to zero. This "bug" was found when trying > to test 10 gigabit and 40 gigabit bandwidth models. These tests were > done on OpenBSD 32bit and 64bit as well as FreeBSD 32bit and 64bit. Nice to hear you've got access to relatively high end gear for testing, I'm sure it will come in handy when the time comes to test any proposed fixes. The obvious workaround in the short term is to do the traffic shaping and filtering a bit closer to the end user, where bandwidth is a bit more scarce. In the slightly longer term, I'm sure a verified bug report (with patches against -current code if feasible) would be much appreciated. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.