From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 3F9EE21F1F9 for ; Wed, 16 Apr 2014 08:30:18 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id b13so11197745wgh.5 for ; Wed, 16 Apr 2014 08:30:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=to1p6Ix4G5UKF9v+nTI9G6eO3raV7uTcBGy4Gs/DTyY=; b=mzfIXF2KClE/6IYwiXwE4l0YQOr+/R7vH/oRRB/aSZ+nX4+1SMMS38vOxf+KDY4MMB 30eeEyQNJCItGb5SiRQe6n2O8V+fJJfgydGGo4nru/P0ZKqLC+3ljN2XRw4lNtWGcAeZ Lx6mljxrQ4eGbe8H1JMm35m17nSamlS+9Ym4TUiD/IAv2dtYc4UH9nKf/TMJH6yTPd71 Yf/gDMxkUxpIKQgkIQOUV8BtJM+W27SjDXLmXE7xtrcTlL+ugXgW0U/0/2Id7e4Qz1d4 mvJfOcxTRS5MeQNZHhdVrb9O+EiRZwtSEEb2VLWmL2xL6JgPj9jLkwTXRrUP5vcAHf/n MloA== MIME-Version: 1.0 X-Received: by 10.194.71.70 with SMTP id s6mr16500wju.94.1397662216127; Wed, 16 Apr 2014 08:30:16 -0700 (PDT) Received: by 10.216.177.10 with HTTP; Wed, 16 Apr 2014 08:30:16 -0700 (PDT) In-Reply-To: <534E323A.2080102@redhat.com> References: <20140318161658.619158b9@redhat.com> <53286AF2.3010203@redhat.com> <534E323A.2080102@redhat.com> Date: Wed, 16 Apr 2014 08:30:16 -0700 Message-ID: Subject: Re: Linux SCTP: what kind of performance should I expect from netperf? From: Dave Taht To: Daniel Borkmann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: bloat-devel X-BeenThere: bloat-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Developers working on AQM, device drivers, and networking stacks" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 15:30:18 -0000 On Wed, Apr 16, 2014 at 12:33 AM, Daniel Borkmann wro= te: > On 04/16/2014 03:23 AM, Dave Taht wrote: > ... > >> It appears I despaired of SCTP's performance too early, >> according to this commit, it just got vastly improved: >> >> >> https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=3D= 362d52040c71f6e8d8158be48c812d7729cb8df1 >> >> way to go daniel! >> >> Have to write some tests for it now! > > > Ok, thanks. That commit needs to be reworked in a different way > by the original authors or us so that it won't hurt performance. > The idea from the original commit is good, but the overall > implementation is not yet fully there it seems. > > >> I do wish someone could get the ledbat linux kernel module up to parity >> with >> at least the osx implementation and get it mainlined. >> >> https://github.com/silviov/TCP-LEDBAT > > > Sounds interesting! If it worked correctly... what appeared to happen at the time I'd tested it is that it never really got into ramping up its window. You could look at it and say "oh, yes, it's scavanging!" but no, it was really stuck at low bandwidth and not taking advantage of the path. Your fix to sctp reminded me of that behavior of this code. I figured it would be a fun weekend project to make tcp-ledbat on linux wor= k, something like 120 weekends ago. (The code has no owner anymore.) certainly it would be awesome and useful if someone could make it work - and at the time I last looked at it, which was pre-BQL, the linux tcp stack was so messed up that I'd thought maybe the problem was elsewhere. And there wasn't a lot of other ledbat code to compare it agains= t, which has changed. But it does look like the code has a bug, see below. netperf has the ability to select congestion control algos on the fly, we have several tests in the netperf-wrapper suite that test the known working tcp cc algorithms (reno, cubic, westwood, lp) against each other, and I'd dearly like a test against uTP. and support for "SCTP_MAERTS" in netperf itself. syntax looks like this - 100mbit empty path: root@comcast-gw:~# netperf -H 172.26.4.1 -t omni -- -K ledbat,ledbat OMNI Send TEST from 0.0.0.0 () port 0 AF_INET to 172.26.4.1 () port 0 AF_INET : demo Local Remote Local Elapsed Throughput Throughput Send Socket Recv Socket Send Time Units Size Size Size (sec) Final Final 65536 87380 65536 10.86 0.31 10^6bits/s root@comcast-gw:~# netperf -H 172.26.4.1 -t omni -- -K lp,lp OMNI Send TEST from 0.0.0.0 () port 0 AF_INET to 172.26.4.1 () port 0 AF_INET : demo Local Remote Local Elapsed Throughput Throughput Send Socket Recv Socket Send Time Units Size Size Size (sec) Final Final 292128 650496 65536 10.02 94.12 10^6bits/s so it's stuck at well below the capability of this path. from a theoretical perspective, ledbat originally aimed at a target delay of 25ms before backing off but that was unachievable in practice, and they went to 100ms. Now that we can reliably via various aqm techniques achieve target delays well below that it would be cool to experiment with a delay based tc= p that could try to back off at 25ms or below... (tom sawyer, trying to make painting a fence more attractive here) --=20 Dave T=C3=A4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article