Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: Cake List <cake@lists.bufferbloat.net>
Subject: Re: [Cake] Cake tin behaviour - discuss....
Date: Sat, 25 Apr 2020 20:34:44 +0000	[thread overview]
Message-ID: <32DE972A-3359-462A-A12C-77714B2563F6@darbyshire-bryant.me.uk> (raw)
In-Reply-To: <4D896254-FFB2-4CEB-B596-A6D2E510243C@gmail.com>

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



> On 25 Apr 2020, at 16:25, Jonathan Morton <chromatix99@gmail.com> wrote:
> 
>> On 25 Apr, 2020, at 2:07 pm, Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> wrote:
>> 
>> Download from ‘onedrive’ from 1 box, using 5 flows, classified as Bulk.  Little other traffic going on, sits there at circa 70Mbit, no problem.
>> 
>> If I started another download on another box, say 5 flows, classified as Best Effort, what rates would you expect the Bulk & Best effort tins to flow at?
> 
> Approximately speaking, Cake should give the Best Effort traffic priority over Bulk, until the latter is squashed down to its tin's capacity.  So you may see 5-10Mbps of Bulk and 65-70Mbps of Best Effort, depending on some short-term effects.
> 
> This assumes that the Diffserv marking actually reaches Cake, of course.

Thanks Jonathan.  I can assure you diffserv markings are reaching cake both egress & ingress due to my pet ‘act_ctinfo/connmark -savedscp’ project.  Amongst other monitoring methods a simple 'watch -t tc -s qdisc show dev $1’ albeit with a slightly modified cake module & tc to report per tin traffic as a percentage of total & per tin % of threshold is used.

eg:
                   Bulk  Best Effort        Video        Voice
  thresh       4812Kbit       77Mbit    38500Kbit    19250Kbit
  target          5.0ms        5.0ms        5.0ms        5.0ms
  interval      100.0ms      100.0ms      100.0ms      100.0ms
  pk_delay        961us        167us        311us        164us
  av_delay        453us         78us        141us         75us
  sp_delay         51us         12us         17us          9us
  backlog         9084b           0b           0b           0b
  pkts         60618617      2006708       460725        11129
  bytes     91414263264   2453185010    636385583      5205008
  traffic%           89            0            0            0
  traftin%         1435            0            0            0
  way_inds      2703134         8957          169          111
  way_miss          922         6192          104          525
  way_cols            0            0            0            0
  drops            8442          230           37            0
  marks               5            0            0            0
  ack_drop            0            0            0            0
  sp_flows            2            3            1            3
  bk_flows            1            0            0            0
  un_flows            0            0            0            0
  max_len         66616        12112         9084         3360
  quantum           300         1514         1174          587

Your expectation is that Best Effort would exert downward pressure on Bulk traffic reducing bulk traffic to about bulk threshold level which is my expectation also.  Tin priority then host (fairness), then flow.

As you may have guessed, that’s not quite what I’m seeing but as I’ve managed to see the issue when using ‘flowblind’ am now much less inclined to point the finger at host fairness & friends.  I remain confused why ‘bulk’ is exceeding its allocation though in what should be pressure from best effort but it ends up going all over the place and being a bit unstable.  Odd.

BTW: The ‘onedrive’ client box is actually running linux.


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2020-04-25 20:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-25 11:07 Kevin Darbyshire-Bryant
2020-04-25 15:14 ` David P. Reed
2020-04-25 15:25 ` Jonathan Morton
2020-04-25 20:34   ` Kevin Darbyshire-Bryant [this message]
2020-04-25 20:56     ` David P. Reed
2020-04-25 21:31       ` Kevin Darbyshire-Bryant
2020-04-26 13:53         ` David P. Reed
2020-04-27 11:52           ` Kevin Darbyshire-Bryant

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=32DE972A-3359-462A-A12C-77714B2563F6@darbyshire-bryant.me.uk \
    --to=kevin@darbyshire-bryant.me.uk \
    --cc=cake@lists.bufferbloat.net \
    --cc=chromatix99@gmail.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