General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Benjamin Cronce <bcronce@gmail.com>
To: Kathleen Nichols <nichols@pollere.com>
Cc: bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] Open Source Speed Test (was fast.com - Netflix's speed monitoring)
Date: Fri, 26 Aug 2016 19:20:03 -0500	[thread overview]
Message-ID: <CAJ_ENFHeXQgoEJRM00xP1RN=bbv9jNu_nAM4ODNdBJZD_kqzDg@mail.gmail.com> (raw)
In-Reply-To: <90667e99-1334-af36-5879-3b4ed362ed68@pollere.com>

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

On Fri, Aug 26, 2016 at 6:13 PM, Kathleen Nichols <nichols@pollere.com>
wrote:

>
> I think it might be useful to say these tests measure the maximum
> *potential* for
> bufferbloat. That is, they plumb the depths of the buffers in the path.
> I tried running
> dslreports while I was running a video and though dslreports ramps
> delays up to 700ms,
> before and after that peak delay is more like 45ms. I don't think large
> buffers are going
>
I would like to know how my ISP is configured. I only know two things. They
are using Calix for the last mile and don't do any rate limiting in the
last mile. They use a Cisco core router where they do all of their rate
limiting. Prior to their Cisco core router, they use the rate limiting on
the ONT. It was strict and created the normal TCP saw-tooth pattern. After
the change over, it was no longer a saw-tooth and more like a high
frequency sine-wave

Here are two speedtests with no traffic shaping on my end,
https://www.dslreports.com/speedtest/4703254
https://www.dslreports.com/speedtest/4703265

This is what it looks like when I enabled Codel on my firewall
https://www.dslreports.com/speedtest/4698506

This is what it looks like when I'm seeding about 20Mb/s and my wife is
watching Netflix while I do a speedtest with Codel
https://www.dslreports.com/speedtest/4702550

Speaking of large buffers. I have been able to get my ISP's AQM to have
massive bursts of latency, but it required my to have my connection DDOSd.
Since the rate limiting is done in the core router for all customers, it
must have a huge buffer. If I have a service DDOS me, used to be 100Mb
connection, with 200Mb/s of UDP, going from perfectly idle to fully
saturated with no ramp-up, I was able to get brief pings into the 4k ms
range before the AQM just started dropping nearly all packets.

What was interesting is after the AQM kicked in, even though I was getting
something like 80% packetloss, my ping stayed around 30ms above idle.

Level 3 comm also seems to have some sort of AQM or they do with my ISP. At
one point my ISP was getting about 15% loss between them and their Level 3
upstream hop. I called up and I was told they were getting DDOSd. Even
during this attack, the ping never spiked more than 20ms to Level 3. Or
Level 3 uses really really small buffers. During this time the ping to my
ISP was its normal healthy stable low value, so I know all of the jitter
was the trunk.

There is hope. It's making its way into hardware, but I would like to know
what hardware and what implementation and why isn't this being more used?

to go away, what matters is whether they are getting filled up.
>
> So, is "bufferbloat" the existence of large buffers or the existence of
> large queues? I think
> the latter.
>
>         Kathie
>
> On 8/24/16 10:28 AM, Livingood, Jason wrote:
> >> Why doesn't the test measure bufferbloat like FLENT or dslreports test?
> >
> > We have not gotten to it yet; it is in our backlog. We’re hoping folks
> might help prior to the hackathon or at the hackathon…  ☺
> >
> > Jason
> >
> >
> > _______________________________________________
> > Bloat mailing list
> > Bloat@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/bloat
> >
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>

[-- Attachment #2: Type: text/html, Size: 4845 bytes --]

      parent reply	other threads:[~2016-08-27  0:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-23 18:42 Livingood, Jason
2016-08-24 16:08 ` Stephen Hemminger
2016-08-24 17:28   ` Livingood, Jason
2016-08-26 23:13     ` Kathleen Nichols
2016-08-26 23:20       ` David Lang
2016-08-26 23:37         ` Kathleen Nichols
2016-08-27  1:06           ` David Lang
2016-08-27  5:02             ` grenville armitage
2016-08-27 12:16             ` Jonathan Morton
2016-08-27  0:20       ` Benjamin Cronce [this message]

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

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

  git send-email \
    --in-reply-to='CAJ_ENFHeXQgoEJRM00xP1RN=bbv9jNu_nAM4ODNdBJZD_kqzDg@mail.gmail.com' \
    --to=bcronce@gmail.com \
    --cc=bloat@lists.bufferbloat.net \
    --cc=nichols@pollere.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