From: Pete Heist <pete@heistp.net>
To: Sebastian Moeller <moeller0@gmx.de>
Cc: ecn-sane@lists.bufferbloat.net
Subject: Re: [Ecn-sane] results of two simple ECN tests
Date: Sun, 17 Feb 2019 21:57:22 +0100 [thread overview]
Message-ID: <F10AD02E-5B25-4566-95F6-E1B845EA2747@heistp.net> (raw)
In-Reply-To: <9FCA2304-8511-4AF6-B860-D42F124A5A32@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 1597 bytes --]
Yes, it's enabled by default. I think I'm just measuring the wrong thing. ECN seems to be about reducing TCP RTT and jitter, not increasing throughput per se. I'll rather compare packet captures with it on and off to look for an improvement in the TCP RTT spikes typically associated with drops.
> On 17 Feb 2019, at 14:02, Sebastian Moeller <moeller0@gmx.de> wrote:
>
> Did you use SACK?
>
>> On February 17, 2019 12:26:51 PM GMT+01:00, Pete Heist <pete@heistp.net> wrote:
>> Attached are some scripts that run two simple tests of ECN with veth devices, with and without ECN. The topology is:
>>
>> client - middlebox (20Mbit htb+fq_codel egress both ways) - net (40ms netem delay both ways, i.e. 80ms RTT) - server
>>
>> Here are some results from the APU2 with Debian 9 / kernel 4.9.0-8:
>>
>> Test 1 (“One vs one”, two clients uploads competing, one flow each for 60 seconds, measure total data transferred):
>>
>> No ECN, 63.2 + 63.5 transferred = 126.7MB
>> ECN, 63.2 + 61.5 transferred = 124.7MB
>>
>> Test 2 (“One vs pulses”, client #1: upload for 60 seconds, client #2: 40x 1M uploads sequentially (iperf -n 1M), measure client #1 data transferred):
>>
>> No ECN, 63.2 MB transferred
>> ECN, 65.0 MB transferred
>>
>> Can anyone suggest changes to this test or a better test that would more clearly show the benefit of ECN? I guess we’d want more congestion and the cost of each lost packet to be higher, meaning higher RTTs and more clients?
>>
>> Pete
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
[-- Attachment #2: Type: text/html, Size: 2054 bytes --]
next prev parent reply other threads:[~2019-02-17 20:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-17 11:26 Pete Heist
2019-02-17 13:02 ` Sebastian Moeller
2019-02-17 20:57 ` Pete Heist [this message]
2019-02-17 21:07 ` Sebastian Moeller
2019-02-18 10:33 ` Pete Heist
2019-02-18 19:24 ` 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
List information: https://lists.bufferbloat.net/postorius/lists/ecn-sane.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=F10AD02E-5B25-4566-95F6-E1B845EA2747@heistp.net \
--to=pete@heistp.net \
--cc=ecn-sane@lists.bufferbloat.net \
--cc=moeller0@gmx.de \
/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