From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (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 D818321F1C0 for ; Thu, 11 Jul 2013 11:37:35 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id f4so18390325iea.39 for ; Thu, 11 Jul 2013 11:37:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=XxlnKcSoTa1l31YKEe8RR6SGHqM+KFYEX+89JvUaO9Y=; b=FHwK/j0HkxKQCYO9lBVkoYUR1y0Og6oSC4M3MwnLFQxzVu+Rn0TQAOY9+7w3EtYEmI 9ul3E1+vs2YkLSFhB7m/Dx1naWwGD7ufv7e4Fh5sqaVTzzxTeoDxf7+xqT5bM23bSQ70 e8WYd/EGDBpc4SXrcoLjRhsPTwJZ3ZN2MSU1Y4EDhZaNZ03akA9/JB9Xr+lhagE42Pkv ToXLO1aL2OgqDz4BznZU72XDrERW1uvurwET8sDjeEyjzamn1EDZD5YZDDFNDJ0jH0id T7c+9c5P+d8e+dhz6A2PljLuvx0E6g0CiuPdDcarIf8HgYl183WSNQkFBJoHZShGEw1K 59gg== MIME-Version: 1.0 X-Received: by 10.50.65.99 with SMTP id w3mr1850936igs.37.1373567855292; Thu, 11 Jul 2013 11:37:35 -0700 (PDT) Received: by 10.64.98.162 with HTTP; Thu, 11 Jul 2013 11:37:35 -0700 (PDT) Date: Thu, 11 Jul 2013 11:37:35 -0700 Message-ID: From: Dave Taht To: codel@lists.bufferbloat.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Codel] useful netem-based testing? 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 18:37:36 -0000 My results with netem were generally so dismal that I'd abandoned it. I just finished building a bunch of kernels from net-next with eric's improvements to it, so I'm about to try it again. My intent is to duplicate most of the RTTs cablelabs simulated with, under essentially the same workloads, as well as things like rrul, rrul_rtt_fair, etc. I intend to be using ipv6 primarily just to make more headaches for myself... and just finished a tc specific script for moving stuff around at varying rtts to different virtual servers here: https://github.com/dtaht/netem-ipv6/blob/master/cablelabs.sh I figure I should switch to drr from prio in order to make this work right? (and obviously the limit needs to be high enough for bandwidth and rtt, haven't done that yet) If anyone has any suggestions as to useful stuff to do with netem (assuming I get sane results with it this time around), now's the time to ask! Certainly I find reordering and packet loss interesting things to dink with, but I'd settle for sane delays to start with.... Now: I haven't started working with netem yet. I'm still validating the behavior of the atom boxes under various workloads, merely talking to each other directly at first, then the other boxes in series (testdriver -> router -> delays -> router(s) -> server(s)) (fast box) -> atom -> atom -> cerowrt -> atom/beaglebone/other boxes One oddity that cropped up is that in turning off offloads entirely at GigE on the two atom boxes the netserver processes peg both cpus (kind of expected), can't achieve full bandwidth (also expected), and that latencies then creep up over a very long test cycle (unexpected) on fq_codel. I figure this is a bug of some sort (cpu scheduler? memory leak somewhere?) and doesn't (visibly) happen with offloads on, and haven't tried 100Mbit yet. http://results.lab.taht.net/maxpacketlimit_300s_NoOffloads_IPv6_1Gbit_Atoms= -5889/maxpacketlimit_300s_Offloads_IPv6_1Gbit_Atoms-fq_codel-all_scaled-rru= l.svg Thinking that perhaps BQL was growing its estimate based on not being able to keep the ethernet device saturated, I set it to a fixed amount... don't think so... http://results.lab.taht.net/maxpacketlimit_300s_NoOffloads_BQL20000_IPv6_1G= bit_Atoms-7228/maxpacketlimit_300s_NoOffloads_BQL20000_IPv6_1Gbit_Atoms-fq_= codel-all_scaled-rrul.svg The slope of the curve for codel also shows a slight overall growth too: http://results.lab.taht.net/maxpacketlimit_300s_NoOffloads_IPv6_1Gbit_Atoms= -5889/maxpacketlimit_300s_Offloads_IPv6_1Gbit_Atoms-codel-all_scaled-rrul.s= vg I am running even longer period tests now. I might just backport the netem changes to 3.10 and try again. the quick n dirty test scripts are here: http://results.lab.taht.net/revised_nfq/ --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html