From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 0FBE03B2A4 for ; Mon, 21 Jan 2019 07:57:51 -0500 (EST) Received: by mail-lj1-x235.google.com with SMTP id q2-v6so17435478lji.10 for ; Mon, 21 Jan 2019 04:57:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LmdmpjZgPBmABD4pHezNI/dKt1nOTjWN4xRuD/39J7s=; b=hmt7rRTsEhgbIKfLNeic3/rltBwWHJmwiD3yYb44pbbs1eOQKDngl0p8l5LxMtsb0W 4dw5hxtBPUW8v1Z+vtEItHwgo4un0q5glkls4WO19LJn5DjeLB+32jgE2txAmFR7pLt0 ZyovpyCUJLAzX1N6VnTgXkd0Yi6v01eA1/oSvziwUHvxJ/CsEoqDg4aOQZZzWIOVuqIX DzWnbDRbNJvSo2EfqqFaVGF9ufcCJACps1kRx9vwU7pch3grDN/O29wPv6iGaF07LSXT U7O2xq8S6qbY2w8Z5yZqiun3PYJJicGaCsgr7TUjLZAXrbKkWZfV5lAf1Mw+f45H7CDX lQbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LmdmpjZgPBmABD4pHezNI/dKt1nOTjWN4xRuD/39J7s=; b=HGhkszd4UWvI0IrWWH7fChNAQm9zRp85EPgIs/cdwVp20ubZau3vCvS2g2IVbPCUTs WMBlejOOFzyM+h/R3GJ3C5sLFj+C2tb6v6Rx5afzLrOs/d3oTsL+4WlFZ+/r2vA4kQry 23837ou2Ik/RKINI+Q+kbDAiVuboZM+4X5adHzuQcSLAoQSbh9mlKbpcYtJrRK3NVLki nt4y1LAjMKH7PWwtWjVJSIvx1K7JDehys+Kfd1yWSMPuKFnuBgzghfN/MdUXgb78w/YW dT4XJODQrHNhFo/Tgr4mycfCXLlH3wazvzSqBnbkYzJscLg8QKnl757bce9WzErlbDr5 lz+g== X-Gm-Message-State: AJcUukdccQ5oDf7GDlbUWtydVDM//cWIrvGo63BJOsZE5G/esC/Znzbv K3AlmuFVrSh8CmcQaqUCQjY= X-Google-Smtp-Source: ALg8bN6iZjYLnRFxAQB/zFRv+thS+7vhZYBfzz3uU/C9jnyj1cMFR77N4h2LuYQtoaEcTe/AQnwP/w== X-Received: by 2002:a2e:2e1a:: with SMTP id u26-v6mr19693861lju.8.1548075469667; Mon, 21 Jan 2019 04:57:49 -0800 (PST) Received: from jonathartonsmbp.lan (83-245-233-163-nat-p.elisa-mobile.fi. [83.245.233.163]) by smtp.gmail.com with ESMTPSA id g70-v6sm2303514ljg.92.2019.01.21.04.57.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 21 Jan 2019 04:57:48 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jonathan Morton In-Reply-To: Date: Mon, 21 Jan 2019 14:57:47 +0200 Cc: Dave Taht , Cake List Content-Transfer-Encoding: quoted-printable Message-Id: <4F9FBE72-2D10-4A9B-8662-EB1691C935F6@gmail.com> 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> To: Shefali Gupta X-Mailer: Apple Mail (2.3445.9.1) 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: Mon, 21 Jan 2019 12:57:51 -0000 > On 21 Jan, 2019, at 1:35 pm, Shefali Gupta = wrote: >=20 > We re-looked into the COBALT implementation to understand why it drops = the first packet later than CoDel. >=20 > There was a bug in the data that was collected in 'drop timestamp = files'. We tried using a different approach to store packet drop times, = and now we see that COBALT indeed drops the first packet prior to = CoDel's first packet drop (image below). So the issue was that our = previous approach of storing the packet drop times in a file was not = correct. >=20 > Let us know your opinion. Okay, good catch. But the more serious problem is with the pattern of drops, which = presently looks much more like BLUE activity (random) than Codel = (ramping frequency). That seems to be unchanged in your new graph. Have you made any progress towards finding out why the queue is = apparently too short? Perhaps log the actual length of the queue when = overflow drops occur. - Jonathan Morton