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 40A842012F7 for ; Fri, 6 Jul 2012 11:10:43 -0700 (PDT) Received: by pbcwz7 with SMTP id wz7so24454600pbc.16 for ; Fri, 06 Jul 2012 11:10:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:date:subject:to :message-id:mime-version:x-mailer; bh=4CavB86qdMtY+YNEO0Y3asNdHNp0q9nqfqVMz4Z6QDM=; b=JU+yrFqjnubgIiZeM+KxgzvBmv09GHA6Dr4OZT1nxS3/ly2VlWqU3Zor/6lsgxhsbu kA/hdamc9rQyflhLweS9ws7y89/eDZN4fGcSYWp+rmmqutEIdqGQ1Qe3galTLuRGrYgS 8VB+byEWneb9wFSZn8/Do7vNTltZZvHP1tdJpP++WK16VlTlzB40HyKnlkVYZHdAIP4T n9yb8wsFC2OOAwvyde3E91OLzrJ2eiwQjedm22w5lqkeS6m5RImtkzEd7sHSqRwv/Dxn wvVkNo/gLoxoGTeUlX40McmGPp/U2M4JyIFKqU2gs9f5WfaercQTN7ns2TDAUT7yQhpN s/Ig== Received: by 10.68.225.201 with SMTP id rm9mr39029003pbc.71.1341598242437; Fri, 06 Jul 2012 11:10:42 -0700 (PDT) Received: from vpn-208-126.usc.edu (vpn-208-126.usc.edu. [128.125.208.126]) by mx.google.com with ESMTPS id qp9sm22300272pbc.9.2012.07.06.11.10.40 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 Jul 2012 11:10:41 -0700 (PDT) From: Anton Mich Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Jul 2012 11:10:38 -0700 To: codel@lists.bufferbloat.net Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Sat, 07 Jul 2012 07:20:25 -0700 Subject: [Codel] 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:10:43 -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? =20 Best, Antonios=