From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.rs.github.com (smtp1-ext.rs.github.com [207.97.227.250]) by huchra.bufferbloat.net (Postfix) with ESMTP id EEEE32010C5 for ; Thu, 12 Jan 2012 22:10:58 -0800 (PST) Received: from github.com (sh1.rs.github.com [172.17.1.41]) by smtp1.rs.github.com (Postfix) with ESMTP id DA28E42921 for ; Thu, 12 Jan 2012 22:10:57 -0800 (PST) Date: Thu, 12 Jan 2012 22:10:57 -0800 From: GitHub To: cerowrt-commits@lists.bufferbloat.net Message-ID: <4f0fcaf1d9243_21e53ffc46a292fc62020@sh1.rs.github.com.mail> Subject: [dtaht/deBloat] : Basic 4Mbit testing and partial log results Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="--==_mimepart_4f0fcaf1d724c_21e53ffc46a292fc61890"; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: cerowrt-commits@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list Reply-To: GitHub List-Id: Development commits for the cerowrt project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 06:10:59 -0000 ----==_mimepart_4f0fcaf1d724c_21e53ffc46a292fc61890 Date: Thu, 12 Jan 2012 22:10:57 -0800 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-ID: <4f0fcaf1d843c_21e53ffc46a292fc619b7@sh1.rs.github.com.mail> Branch: refs/heads/master Home: https://github.com/dtaht/deBloat Commit: d0c4d4f8b7f560962a3541760876cab48bbea0e4 https://github.com/dtaht/deBloat/commit/d0c4d4f8b7f560962a3541760876cab48bbea0e4 Author: Dave Taht Date: 2012-01-12 (Thu, 12 Jan 2012) Changed paths: M src/debloat A test/rtt/itest A test/rtt/notes.org Log Message: ----------- Basic 4Mbit testing and partial log results I put up some test results in the test/rtt directory. I have more detailed logs too, but they point to SFQ working really well to preserve interactive streams. Trying to figure out to what extent red is working vs sfq doing it's job is hard. I need to be monitoring end-to-end stuff, and analyzing the packet captures on both sides. My primary concern is with byte oriented red here and watching iperf misbehave, taking 67 seconds to conclude a test that I had specified 60 for on the 10 stream test. Did I end up with ~7 seconds of buffering in the high rate streams, delaying the FIN/ACK process? Or is it just iperf misbehaving? netperf seems not to... ----==_mimepart_4f0fcaf1d724c_21e53ffc46a292fc61890--