From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 B26553BA8E for ; Fri, 30 Nov 2018 06:54:14 -0500 (EST) Received: by mail-wr1-x42d.google.com with SMTP id q18so5015500wrx.9 for ; Fri, 30 Nov 2018 03:54:14 -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=ia85CPCqJGCMiYv0OGSrTTjRQbdeQN7xMy8bNJ+IY5o=; b=JQm7TgRykn8CAD5aExEPWP7NOun36myZVs6njU6ZmJOkymrDINK36wpDMWpYoXYSpE qkkY6u7ZAJCFKj/gsG0zOJofpZVt57Ku4LXPCy9arMFvaN1HCvljuuxzXFrgXw7dcOWh jnqXK05vs9BPwh5kLoSHEKqlyEF8t3Arr5nfTgEXT+bmfmfHFCp1YjZRj1dsnFfDesEC sa6Chb+EhIoJznoOpDW8IpdcL3mzLOXf3dVZbRGRB+oO+xGanQHQmCturZog/ysQUDlo vdkHtrlmnpPW2ptP/C4UoputRTI1Lclh8Gvh/FuXAOpQMYxqb5L/njF8iwRLllJaI+54 VI3Q== 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=ia85CPCqJGCMiYv0OGSrTTjRQbdeQN7xMy8bNJ+IY5o=; b=hSiLma/o2hzxVSgbelA2j7JO+siWsi0xdQk214KHg6aeDNxvK4+y6ypWweKEw579QG JIlxtXWEsnyXc7wXyhe98xhYT34WbM75GGoF+f07cVoV20Iw5fGS/TrFC0qlOuMgd8dK ihMMBazMpxeXopNdKDttNLZVgOQlT8tL3VsApv52xMqmKY/zvXmIAp8UI95lnq9kMXGm c0cczUnD43ycYGQatyNV2FCK8Wrobi86X92isT/atQKh0gpQgNIJNnS4yVo9pUkByKSj 8hAGn3uhfBOCvbCEvfYd5V0B2qt27IQRSQQbEq5pLAldibrT62iaLrdtB8VpmMitpdaN mhhg== X-Gm-Message-State: AA+aEWZZTtZ/BY2dfPWi/30ckMLPoPEmzq9T4RwZhDDD4FXvkfVt3WIU T11WM7zY9CtcsvbNmQiNTErByvu2NArVjsvYwrk= X-Google-Smtp-Source: AFSGD/Ut9itDDzdiEIx2G5k77fYrkDU4Sf7xARskGxhApPUWcsa0QNaGDukny7tRDtKddvFOMs7RluKcBaZtJc/poOk= X-Received: by 2002:a5d:6889:: with SMTP id h9mr4666618wru.222.1543578853711; Fri, 30 Nov 2018 03:54:13 -0800 (PST) MIME-Version: 1.0 References: <87va4nzsn4.fsf@taht.net> <6578A0D1-FF6A-474E-A6D5-98185F98CB45@gmail.com> In-Reply-To: From: Jendaipou Palmei Date: Fri, 30 Nov 2018 17:23:35 +0530 Message-ID: To: chromatix99@gmail.com Cc: Dave Taht , dave@taht.net, cake@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="000000000000422630057be07587" 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: Fri, 30 Nov 2018 11:54:14 -0000 --000000000000422630057be07587 Content-Type: text/plain; charset="UTF-8" Hi Jonathan, Thanks a lot for the quick review and suggestions to improve the code readability. We incorporated all the changes but didn't see any improvement in the results. However, we finally noticed that it was the packet size used in our simulations that was affecting the throughput. It was earlier set to 1000 bytes, and after making it 1500 bytes (including headers) we note that the throughput is not affected. We have uploaded the new graphs on the same wiki link: https://github.com/Daipu/COBALT/wiki/Light-Traffic We're not sure why packet size is affecting the throughput so largely. Is it the expected behavior? Thanks and Regards Jendaipou Palmei Shefali Gupta On Tue, Nov 27, 2018 at 8:07 PM Jonathan Morton wrote: > > On 27 Nov, 2018, at 4:10 pm, Jendaipou Palmei > wrote: > > > > We have made the changes in the code as suggested. > > > > Here is the diff after making the changes: > > > > > https://github.com/Daipu/COBALT/commit/033db330287e2072bad94ac441f8aed774678a7d > > > > Additionally, we have also updated the values of 'Pincrement' and > 'Pdecrement' (parameters of BLUE) in ns-3 to match the ones used in the > Cake implementation in Linux. > > > > Does the diff look correct? > > It does look like an improvement. How's the behaviour? > > NB: the decimal values used in the constants are not quite precise > equivalents of the Linux values, since you have dropped some of the > trailing digits. You could use (1./256) and (1./4096) to both make them > precise and more human-readable. > > - Jonathan Morton > > --000000000000422630057be07587 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jonathan,

Thanks a lot fo= r the quick review and suggestions to improve the code readability.

We incorporated all the changes but didn't see any im= provement in the results.

However, we finally noti= ced that it was the packet size used in our simulations that was affecting = the throughput. It was earlier set to 1000 bytes, and after making it 1500 = bytes (including headers) we note that the throughput is not affected.

We have uploaded the new graphs on the same wiki link:=
https://github.com/Daipu/COBALT/wiki/Light-Traffic

We're not sure why packet size is affecting the t= hroughput so largely. Is it the expected behavior?

Thanks and Regards
Jendaipou Palmei
Shefali Gupta
<= /div>

On Tue, Nov 27, = 2018 at 8:07 PM Jonathan Morton <chromatix99@gmail.com> wrote:
> On 27 Nov, 2018, at 4:10 pm, Jendaipou Palmei <jendaipoupalmei@gmail.com> wrote:
>
> We have made the changes in the code as suggested.
>
> Here is the diff after making the changes:
>
> https://github.c= om/Daipu/COBALT/commit/033db330287e2072bad94ac441f8aed774678a7d
>
> Additionally, we have also updated the values of 'Pincrement' = and 'Pdecrement' (parameters of BLUE) in ns-3 to match the ones use= d in the Cake implementation in Linux.
>
> Does the diff look correct?

It does look like an improvement.=C2=A0 How's the behaviour?

NB: the decimal values used in the constants are not quite precise equivale= nts of the Linux values, since you have dropped some of the trailing digits= .=C2=A0 You could use (1./256) and (1./4096) to both make them precise and = more human-readable.

=C2=A0- Jonathan Morton

--000000000000422630057be07587--