From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 0AB7A201B52 for ; Fri, 6 Jul 2012 11:20:17 -0700 (PDT) Received: by pbcwz7 with SMTP id wz7so24474073pbc.16 for ; Fri, 06 Jul 2012 11:20:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:references :to:message-id:mime-version:x-mailer; bh=PxUu1wfd5rW0tS88O4b+DQYeUwG8G0jXjBpdSYpR09w=; b=RksBkuxU4y6Ey9yS146ML8ZDjafM9nCZ2Et+oEiaf3eLPhTmblfmEoVmYqCYRctDuV Q3A8ur1YJDKfRRJy9Xzij2Z8+fJaOZBfvybrvBzm4YbHqsAkaMJIsRvqinxq8mdqiRJD q83kHAWzp68UUK2UTO2b1mMn4tplfLtebLoUcdpQeW6KO0PFAfOwGbU+ydKvWcj8BUIt XqqN7OiFZEjD4hmwji0nzcDDyZ7gugo0xcRnA4A6S5GWgyReMYaEyWJl/2x1l/u77UjY yIOOgyO3hN5iu9IematK+zi5lwI2X0a5TbGvoGfMMeuGAcbqxq7Zy1KuZaKWHkQrN87g Blkg== Received: by 10.68.134.161 with SMTP id pl1mr27525890pbb.29.1341598816582; Fri, 06 Jul 2012 11:20:16 -0700 (PDT) Received: from ?IPv6:2001:420:301:1005:226:8ff:feea:2cc1? ([2001:420:301:1005:226:8ff:feea:2cc1]) by mx.google.com with ESMTPS id pe2sm22294902pbc.59.2012.07.06.11.20.14 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 Jul 2012 11:20:15 -0700 (PDT) From: Anton Mich Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Jul 2012 11:20:13 -0700 References: To: codel@lists.bufferbloat.net Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Codel] Fwd: count and rec_inv_sqrt initialization X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 18:20:17 -0000 I'm looking into the Codel implementation in Linux and the ns-2 and ns-3 = simulation and found some inconsistency regarding the behavior of the = count variable. Specifically, in the ACM paper the count is decreased by 2 in the = pseudocode (and ns-3 code) when re-entering a dropping state, in Linux = the count is reduced to the difference of the current count minus the = last count, and in ns-2 the count is reduced by 1. I assume that the = most up to date version is that in linux but for me it's not very = obvious why we set the value of the count like that, departing from the = ACM paper intuition. Also, when testing the Linux codel scheme I discovered the following = behavior: Because rec_inv_sqrt is initialized to 0, it remains 0 under some = specific traffic patterns and that forces the interval/rec_inv_sqrt to a = very small number, no matter what the actual count is. For this not to = happen we have to enter the else statement that sets:=20 =09 else { vars->count =3D 1; vars->rec_inv_sqrt =3D ~0U >> = REC_INV_SQRT_SHIFT; } I found that this behavior is fixed when initializing rec_inv_sqrt like = (reason being that when the newton step is first evaluated, the count is = equal to 1, so we need a good guess of the rec_inv_sqrt): @@ -166,6 +166,7 @@ static void codel_vars_init(struct codel_vars *vars) { memset(vars, 0, sizeof(*vars)); + vars->rec_inv_sqrt =3D ~0U >> REC_INV_SQRT_SHIFT; } Has anybody encountered this behavior? Is this the correct fix? Best, Antonios