Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: Alan Jenkins <alan.christopher.jenkins@gmail.com>
To: Sebastian Moeller <moeller0@gmx.de>
Cc: cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>
Subject: [Cerowrt-devel] YA adsl result, in the UK, download already suprisingly well-shaped
Date: Sat, 7 Mar 2015 19:38:49 +0000	[thread overview]
Message-ID: <CANmMgnF1W4HEq5+hv3AarGm8oyOwreBhuLbkVsWKt_uniOK23A@mail.gmail.com> (raw)

snipped and CC'd for again for record

On 05/03/2015, Sebastian Moeller <moeller0@gmx.de> wrote:
>
> On Mar 5, 2015, at 13:55 , Alan Jenkins <alan.christopher.jenkins@gmail.com>
> wrote:
>
>> On 05/03/2015, Sebastian Moeller <moeller0@gmx.de> wrote:
>>
>>>> I'm only shaping upload, because I can't measure any improvement
>>>> from shaping download.
[which seems kinda hopeful for the cause]

>>> 	Interesting, in my case I need to shape both properly otherwise my
>>> netperf-runner rrul test show too high latencies.

>> Disregard, I suck.  It's not "too high" for me, because I don't use
>> anything like voip.  But there is 10-20ms in it.
>>
>> Last time I gave up getting netperf to on debian (it just kept
>> stalling out).  I ran it on the router, maybe that screwed up the
>> measurements.  Now I have a Fedora to test with and sqm-scripts is
>> definitely living up to the hype :)
>>
>> unshaped:
>>
>> 2015-03-05 12:16:06 Testing against netperf-eu.bufferbloat.net (ipv4)
>> with 5 simultaneous sessions while pinging 89.243.96.1 (60 seconds in
>> each direction)
>> .............................................................
>> Download:  10.84 Mbps
>>  Latency: (in msec, 61 pings, 0.00% packet loss)
>>      Min: 21.100
>>    10pct: 23.700
>>   Median: 34.700
>>      Avg: 34.536
>>    90pct: 47.100
>>      Max: 54.400
>>
>>
>> shaped 12500 (and I'm going to use 11500):
>>
>> Download:  10.14 Mbps
>>  Latency: (in msec, 61 pings, 0.00% packet loss)
>>      Min: 20.800
>>    10pct: 21.400
>>   Median: 23.900
>>      Avg: 24.010
>>    90pct: 26.100
>>      Max: 29.900
>
> 	If you install netperf-wrapper (https://github.com/tohojo/netperf-wrapper)
> and run a test like:
>  date ; ping -c 10 netperf-eu.bufferbloat.net ; ./netperf-wrapper --ipv4 -l
> 300 -H netperf-eu.bufferbloat.net rrul -p all_scaled --disable-log -t
> your_configuration_name_here
>
> you should be able to see even bigger improvements for shaped versus
> unshaped (the rrul test will try to saturate both up and downlink, or use
> /netperfrunner.sh -H netperf-eu.bufferbloat.net to simultaneously load up
> and downlink without netperf-wrapper) I expect almost orders of magnitude
> improvements ;)

I'm being pedantic here, but you're wrong :).  netperf-runner only
shows 5-7ms difference.  That might be part of why I struggled to
measure it last time.

Unshaped:

2015-03-07 19:13:14 Testing netperf-eu.bufferbloat.net (ipv4) with 4
streams down and up while pinging 89.243.96.1. Takes about 30 seconds.
 Download:  9.75 Mbps
   Upload:  0.38 Mbps
  Latency: (in msec, 32 pings, 0.00% packet loss)
      Min: 15.000
    10pct: 15.700
   Median: 30.700
      Avg: 32.297
    90pct: 45.400
      Max: 67.600

Shaped at 11500 (+overhead set to atm, 40 bytes in gui)

 Download:  8.36 Mbps
   Upload:  0.41 Mbps
  Latency: (in msec, 30 pings, 0.00% packet loss)
      Min: 14.600
    10pct: 15.100
   Median: 25.400
      Avg: 25.487
    90pct: 38.600
      Max: 41.100


>>>> Dunno what my ISP has deployed (UK ADSL, "thephone.coop" apparently
>>>> reselling Talk Talk, presumably "LLU") but it gives me some hope :).
>>>
>>> 	If you truly have an adsl
>>
>> No FTTC here!
>
> 	What a pity, ATM encapsulation is awkward, it looked like a decent idea
> while the telco networks seemed to converge on all ATM, but with the move to
> all ethernet, ATM is a relict a fossil that stubbornly refuses to go the way
> of the dodo… VDSL2’s PTM encapsulation is way saner and only costs like 1%
> overhead while ATM comes in at ~9% best case (and due to cell padding can be
> much worse)
>
>>
>>> as compared to a more modern vdsl link, could I
>>> convince you to try the link layer adjustments? If yes, please “holler”;
>>> I
>>> have some basic tools to empirically figure out the per packet overhead
>>> for
>>> ATM-based adel links...
>>
>> I'm very willing to do that.
>
> 	Great, so the first step is to collect a large data set of ping probes. The
> attached shell script

I like your example graph, it may take me a while to try though.
Alan

             reply	other threads:[~2015-03-07 19:38 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-07 19:38 Alan Jenkins [this message]
2015-03-07 19:46 ` Alan Jenkins

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/cerowrt-devel.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CANmMgnF1W4HEq5+hv3AarGm8oyOwreBhuLbkVsWKt_uniOK23A@mail.gmail.com \
    --to=alan.christopher.jenkins@gmail.com \
    --cc=cerowrt-devel@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