From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from homiemail-a86.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by huchra.bufferbloat.net (Postfix) with ESMTP id E100721F1A1 for ; Thu, 11 Jul 2013 08:45:08 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id 32466360082; Thu, 11 Jul 2013 08:45:08 -0700 (PDT) Received: from kmn.local (c-24-6-251-213.hsd1.ca.comcast.net [24.6.251.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nichols@pollere.net) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPSA id 95879360072; Thu, 11 Jul 2013 08:45:06 -0700 (PDT) Message-ID: <51DED2FF.604@pollere.com> Date: Thu, 11 Jul 2013 08:45:03 -0700 From: Kathleen Nichols User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Dave Taht References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Keith Winstein , "codel@lists.bufferbloat.net" Subject: Re: [Codel] sprout X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 15:45:09 -0000 Yes. In point of fact, that is not what I think. I've pointed out the differences a few places. I did do a simulator version of the sfqcodel code that could be configured closer to the fq_codel code at the request/expense of CableLabs. Dave, not completely sure which reservation about maxpacket is in reference. Kathie On 7/10/13 3:44 PM, Dave Taht wrote: > On Wed, Jul 10, 2013 at 3:10 PM, Kathleen Nichols wrote: >> Is that indeed what I think? > > Heh. On another topic, at my stanford talk, you pointed at maxpacket > being a thing > you were a bit dubious about. After fiddling with the concept in > presence of offloads > (which bloat up maxpacket to the size of a tso packet (20k or more)) > I'm more than a bit dubious about it and in my next build of ns2_codel > and nfq_codel > in linux I just capped it at a mtu in the codel_should_drop function: > > if (unlikely(qdisc_pkt_len(skb) > stats->maxpacket && > qdisc_pkt_len(skb) < 1514 )) > stats->maxpacket = qdisc_pkt_len(skb); > > Perhaps in fq_codel the entire maxpacket idea can be junked? > > The problem that I see is that codel switches out of a potential drop > state here and > at almost any workload maxpacket hits a TSO-like size, and at higher workloads > it's too high. I think eric is working on something that will let > overlarge packets just > work and begin to break them down into smaller packets at higher workloads? > > Also > > I'd made a suggestion elsewhere that TSQ migrate down in size from 128k to > lower as the number of active flows increased. Something like > tcp_limit_output_size = max((2*BQL's limit)/(number of flows),mtu) > > but I realize now that tcp has no idea what interface it's going out > at any given > time... still I'm on a quest to minimize latency and let offloads still work.. > > > >