From: Dave Taht <dave.taht@gmail.com>
To: Daniel Borkmann <dborkman@redhat.com>
Cc: bloat-devel <bloat-devel@lists.bufferbloat.net>
Subject: Re: Linux SCTP: what kind of performance should I expect from netperf?
Date: Tue, 18 Mar 2014 12:03:01 -0400 [thread overview]
Message-ID: <CAA93jw5tYv1OJbibxRrytABaoZXbu_d0+1pTWV7Geaotf6mFxg@mail.gmail.com> (raw)
In-Reply-To: <53286AF2.3010203@redhat.com>
On Tue, Mar 18, 2014 at 11:49 AM, Daniel Borkmann <dborkman@redhat.com> wrote:
> On 03/18/2014 04:16 PM, Jesper Dangaard Brouer wrote:
>>
>>
>> Hi Daniel,
>>
>> Can you give some input on this thread?
>>
>> On Tue, 18 Mar 2014 10:53:40 -0400 Dave Taht <dave.taht@gmail.com> wrote:
>>
>>> I was curious about sctp's performance characteristics on
>>> AQM'd systems... so
>>> I built netperf with sctp support, and ran a couple tests on
>>> kernel 3.11...
>>>
>>> +1: SCTP appears to work over IPv6
>>> -1: Throughput is terrible
>
>
> Yes, performance sucks so far (it's a known problem) and
> we need to work on it ... ;-)
I want to make clear that I don't know diddly about SCTP. I DO grok
TCP fairly well...
I got interested in sctp again after hearing a proposal to make
it easier to fq chunks.
> I presume one reason here could be as well that you need to
> do crc32c checksumming on software (what does perf say?).
Well what I think I see is sctp not opening up a window for packets
in flight (as tcp would with cwnd), and basically ping-ponging
sends and acks over the 14ms RTT:
capture here
http://snapon.lab.bufferbloat.net/~d/sctp/
One of my concerns with all the tcp optimization work over the last 3
years was that it might have broken other protocols and stuff that
plugged into the congestion control api for Linux. For example, my
ledbat kernel module behaves similarly, never getting out of slow
start.
But not having a test for sctp in general (I used netperf, is there a better?).
So if SCTP not ramping up is a known problem I can go back to scratching
my head at the ledbat code.
I WAS quite delighted to see SCTP "just work" over ipv6. :)
>
>
>>> d@nuc:~/git/netperf$ netperf -6 -H snapon.lab.bufferbloat.net -t
>>> SCTP_STREAM_MANY
>>> SCTP 1-TO-MANY STREAM TEST from ::0 (::) port 0 AF_INET6 to
>>> snapon.lab.bufferbloat.net () port 0 AF_INET6 : demo
>>> Recv Send Send
>>> Socket Socket Message Elapsed
>>> Size Size Size Time Throughput
>>> bytes bytes bytes secs. 10^6bits/sec
>>>
>>> 212992 212992 4096 10.00 0.31
>>> d@nuc:~/git/netperf$ netperf -6 -H snapon.lab.bufferbloat.net -t
>>> TCP_MAERTS
>>> MIGRATED TCP MAERTS TEST from ::0 (::) port 0 AF_INET6 to
>>> snapon.lab.bufferbloat.net () port 0 AF_INET6 : demo
>>> Recv Send Send
>>> Socket Socket Message Elapsed
>>> Size Size Size Time Throughput
>>> bytes bytes bytes secs. 10^6bits/sec
>>>
>>> 87380 16384 16384 10.00 7.65
--
Dave Täht
Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
next prev parent reply other threads:[~2014-03-18 16:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-18 14:53 Dave Taht
2014-03-18 15:16 ` Jesper Dangaard Brouer
2014-03-18 15:49 ` Daniel Borkmann
2014-03-18 16:03 ` Dave Taht [this message]
2014-04-16 1:23 ` Dave Taht
2014-04-16 7:33 ` Daniel Borkmann
2014-04-16 15:30 ` Dave Taht
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAA93jw5tYv1OJbibxRrytABaoZXbu_d0+1pTWV7Geaotf6mFxg@mail.gmail.com \
--to=dave.taht@gmail.com \
--cc=bloat-devel@lists.bufferbloat.net \
--cc=dborkman@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox