From: Dave Taht <dave.taht@gmail.com>
To: Pete Heist <pete@heistp.net>
Cc: "Jonas Mårtensson" <martensson.jonas@gmail.com>,
bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] powerboost and sqm
Date: Sat, 30 Jun 2018 07:22:38 -0400 [thread overview]
Message-ID: <CAA93jw7GBim=dGUk+29kJMVWqzSkJJSNiT9xO6X+5Mt4XW4vUw@mail.gmail.com> (raw)
In-Reply-To: <BE8C7144-0A3F-41FE-B5DE-AFE9E7BD91C0@heistp.net>
or, like... just ask 'em?
On Sat, Jun 30, 2018 at 3:46 AM Pete Heist <pete@heistp.net> wrote:
>
>
> On Jun 30, 2018, at 8:26 AM, Jonas Mårtensson <martensson.jonas@gmail.com> wrote:
>>
>>
> I played around with flent a bit, here are some example plots:
>
> https://dl.dropbox.com/s/facariwkp5x5dh1/flent.zip?dl=1
>
> The short spikes are not seen with flent so I'm led to believe these are just a result of running the "Hi-Res" dslreports test in a browser. In the flent rrul test, up to about 10 ms induced latency can be seen during the "powerboost" phase but after that it is almost zero. I'm curious about how this is implemented on the ISP side. If anything, sqm seems to induce a bit more latency during the "steady-state" phase.
>
>
> You may also want to try running flent with --socket-stats and making a tcp_rtt plot. You should see a significant difference in TCP RTT between sfq and anything that uses CoDel.
>
> Also, double check the basics- that you’re truly in control of the queue and the device running sqm isn’t running out of CPU and has solid device drivers that aren’t causing periodic pauses or other anomalies (which also follows for your client device). I’ve been sideswiped by such things before when testing sqm, and making theory and experiment fully agree can take science and time.
>
> Pete
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
--
Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
next prev parent reply other threads:[~2018-06-30 11:22 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-29 10:56 Jonas Mårtensson
2018-06-29 11:23 ` Sebastian Moeller
2018-06-30 6:26 ` Jonas Mårtensson
2018-06-30 7:20 ` Jonathan Morton
2018-06-30 7:46 ` Pete Heist
2018-06-30 11:22 ` Dave Taht [this message]
2018-07-01 21:49 ` Jonas Mårtensson
2018-07-04 20:25 ` Benjamin Cronce
2018-06-29 12:22 ` Jonathan Morton
2018-06-29 14:00 ` Dave Taht
2018-06-29 14:42 ` Sebastian Moeller
2018-06-29 15:45 ` Jonas Mårtensson
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='CAA93jw7GBim=dGUk+29kJMVWqzSkJJSNiT9xO6X+5Mt4XW4vUw@mail.gmail.com' \
--to=dave.taht@gmail.com \
--cc=bloat@lists.bufferbloat.net \
--cc=martensson.jonas@gmail.com \
--cc=pete@heistp.net \
/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