From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 6154B3BA8E for ; Wed, 29 Nov 2017 13:51:34 -0500 (EST) Received: by mail-qt0-x234.google.com with SMTP id d15so5669364qte.4 for ; Wed, 29 Nov 2017 10:51:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=3J8tsMeFirQ76b43kdL8OSpWPmYM/CVkpVhWhQz/2MA=; b=vGpB11MCAHlvxMTlHKNth+48AWm5TwN7zyV/WCRmGAk0XR4k9smvt+WS8UrJntM9ZP 2Hgq/y9E3rO0ZA3TdHPHMWeDZ6fyOsYnbaJYFnZiuJbZaBsI0hIiiPCZjatTQtJIFGNx tTqgK1cOwT+i8twbbSTp47HOJ/YJ64Krst+8DnrZOXaqEZLe1fm2GkGSaYCSE3g//Mcn ckydwwjs6Xgo/ObtS826Be6sehnPC24vG2gd4rVg850guw3oZqNx8aXYVA1vonNaMVCO B7eB0VDPQb2/FjWDK1FeO4Gnj6yxzB5xZ2ObJMf5Lsj/rsZKppJAV3PPbx/Doyzmk+4n ZmkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=3J8tsMeFirQ76b43kdL8OSpWPmYM/CVkpVhWhQz/2MA=; b=odxAdC40X7OIerjd9u9mCkR3mne6toVckI/La8sNrBfkSclHcS4gdUVZdMNYyDcLCB HMzu1XGCTBRen2+Gv4CIuWwa7+RPkrPWtobVfGZHeV2p0cUqUtnNH3uoA33S1ihv75Sr Zy72fm4KLfKZujztm6XMBuPbAvDMF0fKJx6cFsyPrLA7Q2slRGF2zUBL/LfEhS8vE+Zo bbOaAwOUHuLztLa/enn4vHYpxBGu9efTlvaPqAj26ETVC7XjEpqASaEht8VqUtyPcT3m wkHoSSLAhOF5+Fj5HH8VZeI2XYTFRnKX8kTFX+KUwSs/XJJAC1ABccINCOe6cnRoehW9 fC0Q== X-Gm-Message-State: AJaThX7+KFPEcpTEmyXr/YlLKH/qBoLYS1MC0Nnd5oyySWsct/mD82+R DsTCAxS6G0PGbNaFSfr9NrwsPAn5bxsY7ZSqilc= X-Google-Smtp-Source: AGs4zMZHBDyKx9nyTZC6YrhxkmH78AWw7f6fiw0aVjik2YdO9uexkoj5bsn4TH6EVWx7iUUPpE2ON+CpUqiVhtKgWyo= X-Received: by 10.237.55.9 with SMTP id i9mr6120171qtb.164.1511981494103; Wed, 29 Nov 2017 10:51:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.193.93 with HTTP; Wed, 29 Nov 2017 10:51:33 -0800 (PST) In-Reply-To: References: <745FEC66-95A7-40E1-A8FA-57714D3AB6AC@gmail.com> <87zi76xlw5.fsf@nemesis.taht.net> <6F2894AD-87EA-4EFC-918E-625E49EDA977@gmail.com> <87o9nmxcbg.fsf@nemesis.taht.net> <87bmjmxbgw.fsf@nemesis.taht.net> <3FAFACA8-C918-4325-BF80-B7EBB6B9B4A7@gmail.com> <87k1y96swh.fsf@toke.dk> <20760855-77A6-456D-BFDB-2A5D17C4528A@gmail.com> <878tep6qdp.fsf@toke.dk> <877eu9x9mp.fsf@nemesis.taht.net> <87tvxdvubi.fsf@nemesis.taht.net> From: Dave Taht Date: Wed, 29 Nov 2017 10:51:33 -0800 Message-ID: To: Georgios Amanakis Cc: Dave Taht , Cake List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] Fwd: cake flenter results round 2 X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 18:51:34 -0000 there is no performance impact of using really high values for netem limit. Stick with 100000. :) (well, there is a cache impact, but that's the cost of correct simulation) On Wed, Nov 29, 2017 at 10:19 AM, Georgios Amanakis w= rote: > I completely neglected this. It turns out sometimes netem drops, sometime= s > it doesn't. > This would also explain the different behaviour I am getting (rrul1) > sometimes. > I guess it is because netem doesn't drop in this case. > > I am attaching a new file with both cases (I could replicate them again). > Delay's netem and mbox's cake stats are in the txt files. > > Is a limit of 4000 a sane value? > Calculated as (0.05s * 900mbit/s / 8bit/byte / 1500bytes/packet)?? > > George > > On Wed, Nov 29, 2017 at 1:00 PM, Dave Taht wrote: >> >> Georgios Amanakis writes: >> >> > ---------- Forwarded message ---------- >> > From: Georgios Amanakis >> > Date: Wed, Nov 29, 2017 at 12:50 PM >> > Subject: Re: [Cake] cake flenter results round 2 >> > To: Dave Taht >> > >> > To avoid a misunderstanding, the delay parameter in both: >> > "ip netns exec delay tc qdisc replace dev delay.r root netem delay 50m= s" >> > "ip netns exec delay tc qdisc replace dev delay.l root netem delay 50m= s" >> >> I would strongly suspect you are seeing drops in these qdiscs also >> without the increased limit, at the increased delay, at 900mbit (go >> check with ip netns exec delay tc -s qdisc show) >> >> My original scripts were targeted at 16Mbit/1mbit and thus I didn't >> change the limit. >> > > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake > --=20 Dave T=C3=A4ht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619