From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) (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 523483BA8E for ; Wed, 23 Jan 2019 12:27:47 -0500 (EST) Received: by mail-yb1-xb35.google.com with SMTP id e12so1178594ybn.10 for ; Wed, 23 Jan 2019 09:27:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=daqqDzVPXB3bXTh0xEARgisQ7ZS0lL4XQ0Rs+rkZc7c=; b=O2voNosrUZ7enY2S63Q5lxf4zOqHMAKXnVCCpEYd7/XpuXRSgk92G5c0Y7Y8PjrbEE +nFawHikxRAZulDM8AK2vMU/mZV9z9UhmuwHugzxy64aWsfOCaxlYWS4PkHB5E3Sq96T 9XVNRfpiC9ZIiw7CNr2lenNwxxnLBNo+nsyDGQ+9XzZomL17pByHCIwZ+HZGaTMtv9hK lfk0dDfOki3Kz3BhtLNaLkhzlZQ4ofhfNr4hWCSBxHAe/8UFiT8ct7St1xeLaVIY5WkO rrSGckUwLB1GELGZXctRVzCHs5OESawIP8EE8YPrKqdw+5VulMmM9vUEg+bw7bre+Xm+ HryQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=daqqDzVPXB3bXTh0xEARgisQ7ZS0lL4XQ0Rs+rkZc7c=; b=fIyxAtXxdeKFutfbtGWsfs1eE5WxPnu+ZO680JV0XigGvFBVWj4MoaC7w2dtu7UmdH caPabc9pTDkyO4jXb/GHN65lIj4B4pQ8fkeT4Yf7DAsdPABTg9pRxSs9x0QRDpxduX2U z4w7pHChYB0rQ2PCahEuHqbhk0M/H9hHnvtSiCN3DYJdJz5XGzO1dtPuvbrhfY+kQjF2 5o2esYCg4+ndCzd3FcWvnYCgbcAceoM3pdKqBFu4JCOYmim0LSdocb+S712vcgpAWus0 CuxfBe9YBnHQ0vgUjnehyMdoHUjD8z/raLHDE+J1jsnUe3O1MsKMo8ksx8fEk9++Q2dr VNUQ== X-Gm-Message-State: AJcUukdSc5pmI7qF0v/apnMm06JLCa5oNmmnK7PhoY6QB2CAZ2SZirSw IJz911yC+OQWIyd55lBPJV0G8NLwSA+jcizMFPg= X-Google-Smtp-Source: ALg8bN4S2abTChxjGNmYs1zBKz5dpy5bm5U/y+6H+y0sVhhRjN6QU9qrJMf6nMINr7v+1nyfbJ2v3K0pvcyD5zglFro= X-Received: by 2002:a25:bb87:: with SMTP id y7mr2914709ybg.321.1548264466648; Wed, 23 Jan 2019 09:27:46 -0800 (PST) MIME-Version: 1.0 References: <87va4nzsn4.fsf@taht.net> <6578A0D1-FF6A-474E-A6D5-98185F98CB45@gmail.com> <08381337-F99A-46D1-87AF-B0F71A8753BC@gmail.com> <949D58FF-9C2F-4516-8547-20A712EC0C92@gmail.com> <271B3584-068F-4FED-B037-B8E920A9EE55@gmail.com> <70BDD881-B509-43FE-81BB-E9C4B1145FA1@gmail.com> <8467184E-7C35-4AFE-9CC6-292215022FDB@gmail.com> <4487BE09-D5D9-4F54-B652-409E50CB4BF4@gmail.com> <75328570-86F6-4BC4-B456-453A4C9FA464@gmail.com> <4F9FBE72-2D10-4A9B-8662-EB1691C935F6@gmail.com> In-Reply-To: From: Shefali Gupta Date: Wed, 23 Jan 2019 22:57:33 +0530 Message-ID: To: Jonathan Morton Cc: Dave Taht , Cake List Content-Type: multipart/alternative; boundary="0000000000008d93b10580236964" Subject: Re: [Cake] COBALT implementation in ns-3 with results under different traffic scenarios 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, 23 Jan 2019 17:27:47 -0000 --0000000000008d93b10580236964 Content-Type: text/plain; charset="UTF-8" Hi Jonathan, Thanks! First, we noticed that cobalt_cache_init method was not implemented in ns-3 COBALT, so we implemented it (but this wasn't the main reason for the wrong behaviour). Later, we found that the data types used in the implementation of COBALT in ns-3 were different from those used in Linux. e.g., uint32_t was used instead of int64_t for the variables with datatype ktime_t in Linux. Results improved considerably after these changes. We will update the wiki with latest results. Regards, Shefali Gupta Jendaipou Palmei On Wed 23 Jan 2019, 9:53 p.m. Jonathan Morton > On 23 Jan, 2019, at 6:19 pm, Shefali Gupta > wrote: > > > > We believe we have spotted the issue now. The new plot is attached below. > > That does look considerably improved. What was the problem in the end? > > Now would be a good time to regenerate all the test graphs, and make sure > there are results for each test for each qdisc tested. Ideally all graphs > should be generated from the same run(s), to ensure their data is mutually > consistent. > > - Jonathan Morton > > --0000000000008d93b10580236964 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jonathan,

Thanks!

First, we noticed that=C2=A0cobalt_cache_= init method was not implemented in ns-3 COBALT, so we=C2=A0implemented=C2= =A0it (but this wasn't the main reason for the wrong behaviour).
<= div style=3D"font-family:sans-serif;font-size:12.8px" dir=3D"auto">
Later= , we found that the data types used in the implementation of COBALT in ns-3= =C2=A0 were different from those used in Linux.

e.g., uint32_t was used in= stead of int64_t for the variables with datatype=C2=A0ktime_t in Linux.

<= /div>
Re= sults improved considerably after these changes.

We will update the wi= ki with latest results.

Regards,
Shefali Gupta
Jendaipou Palmei
On Wed 23 Jan 2019, 9:53 p.m. = Jonathan Morton <chromatix99@gm= ail.com wrote:
> On 23 Jan, = 2019, at 6:19 pm, Shefali Gupta <shefaligups11@gmail.com> wr= ote:
>
> We believe we have spotted the issue now. The new plot is attached bel= ow.

That does look considerably improved.=C2=A0 What was the problem in the end= ?

Now would be a good time to regenerate all the test graphs, and make sure t= here are results for each test for each qdisc tested.=C2=A0 Ideally all gra= phs should be generated from the same run(s), to ensure their data is mutua= lly consistent.

=C2=A0- Jonathan Morton

--0000000000008d93b10580236964--