From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (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 1C27B3B260; Thu, 5 May 2016 12:59:56 -0400 (EDT) Received: by mail-lf0-x236.google.com with SMTP id u64so103441354lff.3; Thu, 05 May 2016 09:59:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fGmBmWvdZUhLr52t8YoyPgxWTsEMZpa/ujvken3HKDs=; b=GCsG3GqOUPu91PPkaIR2gtBpcOEL9Qq7H2t/jI06qvloN+ofbVK30O5ZVuNUcNSmmE 1v5GRWmVgWE/LBN8BAGHYPa+jJrV8mXyNaGyls+/NAvEWsvSEhZq738boBiy3Ubt1oXu 7OYuTnHKRTxc3cwEylnVxYEkDmAxFZpHN25uDMpdKuiAfvMNqnyp85qJMyf5I9LheW2P 4vybziBwWHhAwt8EvTJhWnPACQW8DAhPbt2KkoI8I1qEx7feNrK594QfRGA1436lBvUt vt1q58Pjw6SNl8wFzrVOjp0ZVH88QpStUdoFSe4UrXOSR9vznd1x38Fpfx1N8b2+q5KR g6wQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fGmBmWvdZUhLr52t8YoyPgxWTsEMZpa/ujvken3HKDs=; b=DQsHUk5UhBaUSAE1h0PPM9t5/z2P+0wocHO4WZVs2bhejVZpnendbm5ZyF3nS7T7ET HQOjLp0HZGiNyu+SnZhKqPJTIzhRp4KlwXh2KU/XNV/Su4jQQM9MgctQWD0N/OK4vXhH 8QTLiL/Ez6jpZsG4fASS1knjn8F6YbN2J+QRN7Wy4XinHLHQBHZeCtVr4rnvbZvlrpGN ms8WsHQFgsRRZE7PWBxzD4u15eJ/jI9BVjy7K1s9C+pmPy5HV8DNngEk5EddGWvZkRXC HWpcOQ9+YPd2dkvwVXQMLUJm4KNQnoJxSJTnYeREtt6V2RcRij/4/uubv1v3nFdsSibS o6oQ== X-Gm-Message-State: AOPr4FWf8Mf9sLBWvucX8lc0hC7vLMubs2Bo/XZjmeuE+nfVH3rQS0079r5cBwx5oSzCxQ== X-Received: by 10.112.198.198 with SMTP id je6mr7365457lbc.140.1462467594735; Thu, 05 May 2016 09:59:54 -0700 (PDT) Received: from bass.home.chromatix.fi (87-93-84-153.bb.dnainternet.fi. [87.93.84.153]) by smtp.gmail.com with ESMTPSA id ku5sm1687774lbc.11.2016.05.05.09.59.53 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 May 2016 09:59:53 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jonathan Morton In-Reply-To: Date: Thu, 5 May 2016 19:59:51 +0300 Cc: Dave Taht , Eric Dumazet , make-wifi-fast@lists.bufferbloat.net, "codel@lists.bufferbloat.net" , ath10k Content-Transfer-Encoding: quoted-printable Message-Id: <2D83E4F6-03DD-4421-AAE0-DD3C6A8AFCE0@gmail.com> References: <1462125592.5535.194.camel@edumazet-glaptop3.roam.corp.google.com> <865DA393-262D-40B6-A9D3-1B978CD5F6C6@gmail.com> <1462128385.5535.200.camel@edumazet-glaptop3.roam.corp.google.com> <1462136140.5535.219.camel@edumazet-glaptop3.roam.corp.google.com> <1462201620.5535.250.camel@edumazet-glaptop3.roam.corp.google.com> <1462205669.5535.254.camel@edumazet-glaptop3.roam.corp.google.com> To: Roman Yeryomin X-Mailer: Apple Mail (2.3124) Subject: Re: [Codel] fq_codel_drop vs a udp flood X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2016 16:59:56 -0000 > Having same (low) speeds. > So it didn't help at all :( Although the new =E2=80=9Cemergency drop=E2=80=9D code is now dropping = batches of consecutive packets, Codel is also still dropping individual = packets in between these batches, probably at a high rate. Since all = fragments of an original packet are required to reassemble it, but Codel = doesn=E2=80=99t link related fragments when deciding to drop, each = fragment lost in this way reduces throughput efficiency. Only a = fraction of the original packets can be reassembled correctly, but the = surviving (yet useless) fragments still occupy link capacity. This phenomenon is not Codel specific; I would also expect to see it on = most other AQMs, and definitely on RED variants, including PIE. = Fortunately for real traffic, it normally arises only on artificial = traffic such as iperf runs with large UDP packets. Unfortunately for = AQM advocates, iperf uses large UDP packets by default, and it is very = easy to misinterpret the results unfavourably for AQM (as opposed to = unfavourably for iperf). If you re-run the test with iperf set to a packet size compatible with = the path MTU, you should see much better throughput numbers due to the = elimination of fragmented packets. A UDP payload size of 1280 bytes is = a safe, conservative figure for a normal MTU in the vicinity of 1500. > Limit of 1024 packets and 1024 flows is not wise I think. >=20 > (If all buckets are in use, each bucket has a virtual queue of 1 = packet, > which is almost the same than having no queue at all) This, while theoretically important in extreme cases with very large = numbers of flows, is not relevant to the specific test in question. - Jonathan Morton