From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 3294121F1AD; Mon, 8 Jul 2013 23:32:04 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id u16so12246635iet.9 for ; Mon, 08 Jul 2013 23:32:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Jb+3cjtkWdwXgXRk3DGnRLaCLjX655cMRcvCccdldw0=; b=KOhVCjqC4O8desgrI3Zvt0SCn1ETI1YO+aDJiKmImrg1oZuRSlH1VN0QWoNT0pv4rb +Ay55qr77RCjc8DMVgvJLqF1IpbDrf1k6cus27MnkcjwoDt6Iiz49nQFgVhulwQr/csu oOXL4uFSaWQBqbn7HpfzMdlLpxlV2tB74oJyDxuan/lYXOCVAVFxSvYXdrpY5Vup+r6X DyXvvqbVvwGSLk+YFeNFlHxA8G8Y/1TqZmX6CyGvRN3NawfE0At8hu/y6xddSzGFrKon NHlVOMRzvWJ60Y4/bZ3vVmPPWyDZUZdM9XuYmhKfEY6UK5utmf7FGYW6lzOnIKL7xSsd aOmQ== MIME-Version: 1.0 X-Received: by 10.50.3.103 with SMTP id b7mr33052690igb.54.1373351523376; Mon, 08 Jul 2013 23:32:03 -0700 (PDT) Received: by 10.64.86.8 with HTTP; Mon, 8 Jul 2013 23:32:03 -0700 (PDT) In-Reply-To: References: <1373223178.486913695@apps.rackspace.com> <871u79x9kb.fsf@toke.dk> Date: Mon, 8 Jul 2013 23:32:03 -0700 Message-ID: From: Dave Taht To: Mikael Abrahamsson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: =?ISO-8859-1?Q?Toke_H=F8iland=2DJ=F8rgensen?= , codel@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net Subject: Re: [Codel] [Cerowrt-devel] happy 4th! 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: Tue, 09 Jul 2013 06:32:04 -0000 this really, really, really is the wrong list for this dialog. cc-ing codel On Mon, Jul 8, 2013 at 11:04 PM, Mikael Abrahamsson wrot= e: > On Mon, 8 Jul 2013, Toke H=F8iland-J=F8rgensen wrote: > >> Did a few test runs on my setup. Here are some figures (can't go higher >> than 100mbit with the hardware I have, sorry). > > > Thanks, much appreciated! > > >> Note that I haven't done tests at 100mbit on this setup before, so can't >> say whether something weird is going on there. I'm a little bit puzzled >> as to why the flows don't seem to get going at all in one direction for >> the rrul test. I'm guessing it has something to do with TSQ. > > > For me, it shows that FQ_CODEL indeed affects TCP performance negatively = for > long links, however it looks like the impact is only about 20-30%. I would be extremely reluctant to draw any conclusions from any test derived from netem's results at this point. (netem is a qdisc that can insert delay and loss into a stream) I did a lot of netem testing in the beginning of the bufferbloat effort and the results differed so much from what I'd got in the "real world" that I gave up and stuck with the real world for most of the past couple years. There were in particular, major problems with combining netem with any other qdisc... https://www.bufferbloat.net/projects/codel/wiki/Best_practices_for_benchmar= king_Codel_and_FQ_Codel One of the simplest problems with netem is that by default it delays all packets, including things like arp and nd, which are kind of needed in ethernet... That said, now that more problems are understood, toke and I, and maybe matt mathis are trying to take it on... The simulated results with ns2 codel were very good in the range 2-300ms, but that's not the version of codel in linux. It worked well up to about 1sec, actually, but fell off afterwards. I have a set of more ns2-like patches for the ns2 model in cerowrt and as part of my 3.10 builds that I should release as a deb soon. Recently a few major bugs in htb have come to light and been fixed in the 3.10 series. There have also been so many changes to the TCP stack that I'd distrust comparing tcp results between any given kernel version. The TSQ addition is not well understood, and I think, but am not sure, it's both too big for low bandwidths and not big enough for larger ones... and... unlike in the past where tcp was being optimized for supercomputer center to supercomputer center, the vast majority of tcp related work is now coming out of google, who are optimizing for short transfers over short rtts. It would be nice to have access to internet2 for more real world testing. > > What's stranger is that latency only goes up to around 230ms from its 200= ms > "floor" with FIFO, I had expected a bigger increase in buffering with FIF= O. TSQ, here, probably. > Have you done any TCP tuning? Not recently, aside from turning up tsq to higher defaults and lower defaults without definitive results. > Would it be easy for you to do tests with the streams that "loads up the > link" being 200ms RTT, and the realtime flows only having 30-40ms RTT, > simulating downloads from a high RTT server and doing interactive things = to > a more local web server. It would be a useful workload. Higher on my list is emulating cablelab's latest tests, which is about the same thing only closer statistically to what a real web page might look like - except cablelabs tests don't have the redirects or dns lookups most web pages do. > > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html