Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: Dave Taht <dave.taht@gmail.com>
To: Cake List <cake@lists.bufferbloat.net>,
	cerowrt-devel@lists.bufferbloat.net
Subject: [Cake] inbound cake or fq_codel shaping fails on cable on netflix reno
Date: Sat, 21 Jul 2018 09:09:59 -0700	[thread overview]
Message-ID: <CAA93jw6k-esNU8by-Z=j7n0SVTVGPY6=Z+nR_TGwdLGSVOCi+Q@mail.gmail.com> (raw)

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

This is something I noticed years ago, inspired me to think about a
"bobbie" policer, and I decided I could live with, and never poked
into further. After our successes with shaping inbound cable at
then-typical 20mbit rates, I was happy, although never satisifed with
the 85% magic number we use to come up with a set rate for inbound
shaping.

Simultaneously with all that work we did on sqm, linux added tcp tsq,
pacing, etc, etc and in general inbound shaping cable seems to work ok
against one or more linux tcp flows. We end up with some persistent
queuing delay (at the cmts in the 5-15ms range) which I've generally
assumed was unavoidable that fq cannot cut through (oh, I dream of FQ
at the CMTS!)

BUT: In testing fast.com's test, I see it fail to shape it to anything
sane, with spikes of up to 160ms.

So, anyway, I've seen this pathology before with netflix flows. What I
didn't realize then was that it was independent of the shaped rate.
(see plots) It's independent of the rtt setting in cake too (at least,
down to 25ms). My assumption is the netflix (freebsd) traffic + the
cable is so bursty as to not let codel keep improving its drop rate.

I'm curious if it's also the case on other link layer techs (dsl, fiber)?

The structure of my test is simple: shape inbound to 80% of the
cablemodem rate, setup irtt (not strictly needed), start this,

root # flent -H flent-fremont.bufferbloat.net -t 'your_location' -s .02 ping

, let it run a few sec, then run the fast.com test.

I tried to verify this using linux reno on a recent kernel, but that
seemed healthy. Assuming it actually got reno. Or that this weirdness
is a function of the RTT.

1) Can someone else on a cablemodem (even without the latest cake,
this happens to me on older cake and fq_codel) try this test?
2) Can someone with a dsl or fiber device try this test?
3) Is there a freebsd box "out on the net", 45ms or so from me, we can
setup netperf/irtt/etc on to run flent with? (I can donate a linode in
LA I but we'd need someone that can setup freebsd)

Some pics attached, flent data files at:
http://www.taht.net/~d/fast_vs_cable.tgz

PS I also have two other issues going on. This is the first time I've
been using irtt with a 20ms interval, and I regularly see single 50+ms
spikes (in both ping and irtt) data and also see irtt stop
transmitting. On this front, it could merely be that my (not tested in
months!) test cablemodem setup is malfunctioning also! Or we're
hitting power save. Or (finally) seeing request-grant delays. Or
scheduling delay somewhere in the net-next kernel I'm using... Or....
(regardless, this seems independent of my main issue, and I've not had
such high res data before)
-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com

[-- Attachment #2: ping_-_flent-newark-reno.png --]
[-- Type: image/png, Size: 134097 bytes --]

[-- Attachment #3: ping_-_shape_fail_60mbit.png --]
[-- Type: image/png, Size: 51478 bytes --]

[-- Attachment #4: ping_-_shape_fail_40mbit.png --]
[-- Type: image/png, Size: 61707 bytes --]

             reply	other threads:[~2018-07-21 16:10 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-21 16:09 Dave Taht [this message]
2018-07-21 17:20 ` Georgios Amanakis
2018-07-21 17:23   ` Jonathan Morton
2018-07-21 17:44     ` Georgios Amanakis
2018-07-21 17:47       ` Dave Taht
2018-07-21 18:17         ` Georgios Amanakis
2018-07-21 18:20           ` Dave Taht
2018-07-21 18:23             ` Georgios Amanakis
2018-07-21 20:01           ` Dave Taht
2018-07-21 20:24             ` Jonathan Morton
2018-07-21 20:36               ` Dave Taht
2018-07-21 21:17                 ` Arie
2018-07-21 21:37                   ` Dave Taht
2018-07-21 22:13                     ` Dave Taht
2018-07-21 22:28                       ` Dave Taht
2018-07-21 23:10                       ` Arie
2018-07-23  6:50                         ` Ryan Mounce
2018-07-23 14:56                           ` Dave Taht
2018-07-23 15:26                             ` Jonas Mårtensson
2018-07-23 15:43                               ` Dave Taht
2018-07-23 16:45                               ` Tristan Seligmann
2018-07-23 20:47                                 ` Dave Taht
2018-07-23 15:49                             ` Sebastian Moeller
2018-07-23 17:32                             ` Benjamin Cronce
     [not found]                           ` <CAA93jw7hPG5oGyKaCL69p9Sbf7BckAZzh-p8C0jU+QXF9she1A@mail.gmail.com>
2018-07-24  1:31                             ` Ryan Mounce
2018-07-24  2:17                               ` Ryan Mounce
2018-07-24  2:29                                 ` Dave Taht
2018-07-24  2:50                                   ` Ryan Mounce
2018-07-24  8:15                                     ` Kevin Darbyshire-Bryant
2018-07-24 13:51                                       ` Dave Taht
2018-07-24 14:54                                         ` Kevin Darbyshire-Bryant
2018-07-24 15:19                                           ` Dave Taht
2018-07-24 18:05                                             ` Tristan Seligmann
2018-07-24 18:08                                               ` Tristan Seligmann
2018-07-24 17:58                                           ` Sebastian Moeller
2018-07-24 19:38                                         ` Pete Heist
2018-07-24 20:44                                           ` Dave Taht
2018-07-24 22:23                                             ` Pete Heist
2018-07-24 22:29                                               ` Dave Taht
2018-07-24 22:43                                                 ` Pete Heist
2018-07-21 17:24   ` Arie
2018-07-21 17:27     ` Dave Taht
2018-07-21 17:36       ` Arie
2018-07-21 17:45         ` Dave Taht
2018-07-21 17:55           ` Arie
2018-07-21 18:02             ` Dave Taht
2018-07-21 18:23               ` Arie
     [not found]                 ` <CAA93jw64CbM9DmtHM2aRbFBb3TUepSAK2JRmcDZHZ6kUkJB1Jg@mail.gmail.com>
2018-07-21 18:38                   ` [Cake] policers, finally Dave Taht
2018-07-21 18:45                     ` Dave Taht
2018-08-04  7:53                       ` [Cake] Policers Dave Taht
2018-07-21 17:28   ` [Cake] inbound cake or fq_codel shaping fails on cable on netflix reno Georgios Amanakis
2018-07-21 17:42     ` Dave Taht
2018-07-21 19:57       ` [Cake] [Cerowrt-devel] " Toke Høiland-Jørgensen
2018-07-24  2:36   ` [Cake] " Dave Taht
2018-07-24  4:17     ` Georgios Amanakis
2018-07-22  9:57 ` Pete Heist
2018-07-22 10:29   ` Sebastian Moeller

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

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

  git send-email \
    --in-reply-to='CAA93jw6k-esNU8by-Z=j7n0SVTVGPY6=Z+nR_TGwdLGSVOCi+Q@mail.gmail.com' \
    --to=dave.taht@gmail.com \
    --cc=cake@lists.bufferbloat.net \
    --cc=cerowrt-devel@lists.bufferbloat.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