From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: Linux TCP's Robustness to Multipath Packet Reordering Date: Tue, 26 Apr 2011 23:08:12 +0200 Message-ID: <1303852092.2699.11.camel@edumazet-laptop> References: <1303730701.2747.110.camel@edumazet-laptop> <1303850622.2699.6.camel@edumazet-laptop> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Carsten Wolff , netdev@vger.kernel.org To: Dominik Kaspar Return-path: Received: from mail-ww0-f44.google.com ([74.125.82.44]:44632 "EHLO mail-ww0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758184Ab1DZVIR (ORCPT ); Tue, 26 Apr 2011 17:08:17 -0400 Received: by wwa36 with SMTP id 36so1180753wwa.1 for ; Tue, 26 Apr 2011 14:08:16 -0700 (PDT) In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: Le mardi 26 avril 2011 =C3=A0 23:04 +0200, Dominik Kaspar a =C3=A9crit = : > In these experiments, a queue size of 1000 packets was specified. I a= m > aware that this is typically referred to as "buffer bloat" and causes > the RTT and the cwnd to grow excessively. The smaller I configure the > queues, the more time it takes for TCP to "level up" to the aggregate > throughput. By keeping the queues so large, I hope to more quickly > identify the reason why TCP is actually able to adjust to the immense > multipath reordering. What parameters could be highly relevant, other > than the queue size? >=20 losses of course ;) Real internet is full of packet losses, and probability of these losses depends on queue sizes (RED like AQM) > Thanks for the tip about printing tc/netem statistics after each run, > I will use "tc -s -d qdisc" next time. >=20