Historic archive of defunct list cerowrt-commits@lists.bufferbloat.net
 help / color / mirror / Atom feed
* [dtaht/deBloat] : Basic 4Mbit testing and partial log results
@ 2012-01-13  6:10 GitHub
  0 siblings, 0 replies; only message in thread
From: GitHub @ 2012-01-13  6:10 UTC (permalink / raw)
  To: cerowrt-commits

[-- Attachment #1: Type: text/plain, Size: 1099 bytes --]

  Branch: refs/heads/master
  Home:   https://github.com/dtaht/deBloat
  Commit: d0c4d4f8b7f560962a3541760876cab48bbea0e4
      https://github.com/dtaht/deBloat/commit/d0c4d4f8b7f560962a3541760876cab48bbea0e4
  Author: Dave Taht <d@taht.net>
  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...




^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2012-01-13  6:10 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-01-13  6:10 [dtaht/deBloat] : Basic 4Mbit testing and partial log results GitHub

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox