From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-03-ewr.dyndns.com (mxout-081-ewr.mailhop.org [216.146.33.81]) by lists.bufferbloat.net (Postfix) with ESMTP id C762C2E0400 for ; Sun, 3 Apr 2011 11:19:28 -0700 (PDT) Received: from scan-01-ewr.mailhop.org (scanner [10.0.141.223]) by mail-03-ewr.dyndns.com (Postfix) with ESMTP id 2D0CB786CAB for ; Sun, 3 Apr 2011 18:19:28 +0000 (UTC) X-Spam-Score: 0.0 () X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 213.186.56.95 Received: from witko.kerneis.info (witko.kerneis.info [213.186.56.95]) by mail-03-ewr.dyndns.com (Postfix) with ESMTP id 7D74E7869C0 for ; Sun, 3 Apr 2011 18:19:24 +0000 (UTC) Received: from [2001:0:53aa:64c:24f3:690d:b106:18ef] (helo=trurl.pps.jussieu.fr) by witko.kerneis.info with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Q6RtT-000640-SC for bloat@lists.bufferbloat.net; Sun, 03 Apr 2011 20:19:23 +0200 Received: from jch by trurl.pps.jussieu.fr with local (Exim 4.74) (envelope-from ) id 1Q6RtS-00013q-6Z for bloat@lists.bufferbloat.net; Sun, 03 Apr 2011 20:19:22 +0200 From: Juliusz Chroboczek To: bloat@lists.bufferbloat.net Date: Sun, 03 Apr 2011 20:19:22 +0200 Message-ID: <87vcyv19lh.fsf@trurl.pps.jussieu.fr> MIME-Version: 1.0 Content-Type: text/plain X-SA-Exim-Connect-IP: 2001:0:53aa:64c:24f3:690d:b106:18ef X-SA-Exim-Mail-From: jch@pps.jussieu.fr X-SA-Exim-Scanned: No (on witko.kerneis.info); SAEximRunCond expanded to false Subject: [Bloat] SFB and Dan Siemon's tests X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 18:19:29 -0000 Hi, I've finally found some time to try to understand Dan Siemon's results on http://www.coverfire.com/archives/2011/02/21/network-latency-experiments/ That's some excellent work, Dan, a lot of thanks for it. If I read it right, the BDP is 5 packets (4Mbit/s times 15ms), and SFB is being run with a per-flow queue length of 20 packets (the default); hence, it should be able to swallow the bursts necessary in order to fill the link. The chaotic variations in latency, as well as the high packet loss, indicate that either there's something wrong with the implementation, or that somebody somewhere is sending massive bursts of packets that sfb is discarding, as it is designed to do. It would be good to have a graph of packet loss as a function of time, in order to check if SFB is converging too slowly in this case. -- Juliusz