From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id BF0D521F2B4; Wed, 25 Mar 2015 21:52:07 -0700 (PDT) Received: by labto5 with SMTP id to5so36669780lab.0; Wed, 25 Mar 2015 21:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wRYSZRiupLPUmcYIiP8rbehwO61I5eESoIDRqhlkKGs=; b=sAQ4FMnxuEjK8Zo/kQPI0bZFHMQXnCLPbqs+ezAjmV3Dc9BJwfKIFlDwwUpPuGjH2b ay2cBNQY/O3RykPyouKyy3BZmCWj0xb2/S+eaRAZxr8M0Qx6EiAUXbihlL9pq3np8Xtr GOPmCR21EXKxZVY0IsuztFx+ntscgWG1IIshaFtsyz7DG2hG6tcLVC7BjQKbDwmGsvgh 9hLdW9jSRlF+WrOGrJgX0dTfpB08t0sn0mltDPS5oXT8LXbX8hTvpdvVq9H1CyDWZFMF edvtDa2mEnq/y9dU6EOo76fIgTdTBUgMgzeyzIMzzrwaJlqELIX5dql6DUeF9hN51tS9 WCoA== X-Received: by 10.152.19.199 with SMTP id h7mr11976203lae.32.1427345524863; Wed, 25 Mar 2015 21:52:04 -0700 (PDT) Received: from bass.home.chromatix.fi (37-136-34-134.rev.dnainternet.fi. [37.136.34.134]) by mx.google.com with ESMTPSA id ef8sm1012879lbd.0.2015.03.25.21.52.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Mar 2015 21:52:04 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: fixing netem to be more useful From: Jonathan Morton In-Reply-To: Date: Thu, 26 Mar 2015 06:52:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1F6C20F9-8246-42E2-8AE3-FF2D33CE1DFB@gmail.com> References: To: Dave Taht X-Mailer: Apple Mail (2.2070.6) Cc: "codel@lists.bufferbloat.net" , bloat-devel , bloat X-BeenThere: bloat-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Developers working on AQM, device drivers, and networking stacks" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 04:52:36 -0000 > On 25 Mar, 2015, at 19:32, Dave Taht wrote: >=20 > On of my big issues with netem (a network emulator for linux that lets > you do delay, loss, etc) is that there is no way to setup multiple RTT > emulations without having a separate maximum number of packets limit > for each, which can really skew the results. I would like to see a > netem that had a multi-queue implementation with a shared limit, among > other things. Hold on - what does the packet limit control? Is it the total number of = packets in virtual transit and in the queue proper, or just those in = virtual transit? The former would certainly interact badly with = superimposed qdiscs (which should have their own resource limits), but = the latter would imply that the limit is just a safety factor (which = should be set high, if it=E2=80=99s running on desktop hardware) rather = than a performance knob. It strikes me that there might be a fundamental design problem here - = where is the line drawn between the queue before the emulated network = and the emulated link itself? If that were made explicit (eg. by making = netem classful with a single class, and thus enforcing the existence of = a subordinate qdisc), it might behave better in general. Then, a related problem would be how to assign different delays and loss = rates to different traffic (thus emulating a more complex network) while = still funnelling all of it through the same subordinate qdisc. > Is there anyone working on making netem better? is there someone > willing to work on it that someone could fund? I might be able to justify rolling that into my tinkering with cake. - Jonathan Morton