Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: Dave Taht <dave.taht@gmail.com>
To: Sebastian Moeller <moeller0@gmx.de>
Cc: Georgios Amanakis <gamanakis@gmail.com>,
	Cake List <cake@lists.bufferbloat.net>
Subject: Re: [Cake] cake flenter results round 1
Date: Mon, 27 Nov 2017 09:38:45 -0800	[thread overview]
Message-ID: <CAA93jw6n+MUAT6KVnyJ4fSg9jiWBB9qLiMRzHW8LkwKE2kEgrQ@mail.gmail.com> (raw)
In-Reply-To: <2A5F940F-F713-4578-8123-5CAD98A9C4C3@gmx.de>

On Mon, Nov 27, 2017 at 9:34 AM, Sebastian Moeller <moeller0@gmx.de> wrote:
> But 444.35 + 443.65 = 888, no?

My bad. I miss-read the test setup. Pre-coffee here, though, that
caused an adrenalin spike.

Yea! per host fairness 1v12! and correct bandwidth on this cpu. :whew:

>
>> On Nov 27, 2017, at 18:33, Dave Taht <dave.taht@gmail.com> wrote:
>>
>> georgios
>>
>> the result you got was "fair", but you shoul have seen something
>> closer to 900mbit than 400.
>>
>> On Mon, Nov 27, 2017 at 8:17 AM, Georgios Amanakis <gamanakis@gmail.com> wrote:
>>> Dear Pete,
>>>
>>> I am trying to replicate the unfair behaviour you are seeing with
>>> dual-{src,dst}host, albeit on different hardware and I am getting a fair
>>> distribution. Hardware are Xeon E3-1220Lv2 (router), i3-3110M(Clients). All
>>> running Archlinux, latest cake and patched iproute2-4.14.1, connected with
>>> Gbit ethernet, TSO/GSO/GRO enabled.
>>>
>>> Qdisc setup:
>>> ----------------
>>> Router:
>>> qdisc cake 8003: dev ens4 root refcnt 2 bandwidth 900Mbit diffserv3
>>> dual-dsthost rtt 100.0ms raw
>>>
>>> Client A(kernel default):
>>> qdisc fq_codel 0: dev eno2 root refcnt 2 limit 10240p flows 1024 quantum
>>> 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
>>>
>>> Client B (kernel default):
>>> qdisc fq_codel 0: dev enp1s0 root refcnt 2 limit 10240p flows 1024 quantum
>>> 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
>>> ----------------
>>>
>>>
>>> Cli:
>>> ----------------
>>> Router:
>>> netserver &
>>>
>>> Client A:
>>> flent tcp_1down -H router
>>>
>>> Client B:
>>> flent tcp_12down -H router
>>> ----------------
>>>
>>>
>>> Results:
>>> ----------------
>>> Router:
>>> qdisc cake 8003: root refcnt 2 bandwidth 900Mbit diffserv3 dual-dsthost rtt
>>> 100.0ms raw
>>> Sent 7126680117 bytes 4725904 pkt (dropped 10, overlimits 4439745 requeues
>>> 0)
>>> backlog 0b 0p requeues 0
>>> memory used: 1224872b of 15140Kb
>>> capacity estimate: 900Mbit
>>>                 Bulk   Best Effort      Voice
>>>  thresh     56250Kbit     900Mbit     225Mbit
>>>  target         5.0ms       5.0ms       5.0ms
>>>  interval     100.0ms     100.0ms     100.0ms
>>>  pk_delay        14us       751us         7us
>>>  av_delay         2us       642us         1us
>>>  sp_delay         1us         1us         1us
>>>  pkts          109948     4601651       14315
>>>  bytes      160183242  6964893773     1618242
>>>  way_inds           0       21009           0
>>>  way_miss         160         188           5
>>>  way_cols           0           0           0
>>>  drops              0          10           0
>>>  marks              0           0           0
>>>  ack_drop           0           0           0
>>>  sp_flows           0           1           1
>>>  bk_flows           1           0           0
>>>  un_flows           0           0           0
>>>  max_len         7570       68130        1022
>>>
>>>
>>> Client A:
>>>                           avg       median          # data pts
>>> Ping (ms) ICMP :         0.11         0.08 ms              350
>>> TCP download   :       443.65       430.38 Mbits/s         301
>>>
>>>
>>> Client B:
>>>                             avg       median          # data pts
>>> Ping (ms) ICMP   :         0.09         0.06 ms              350
>>> TCP download avg :        37.03        35.87 Mbits/s         301
>>> TCP download sum :       444.35       430.40 Mbits/s         301
>>> TCP download::1  :        37.00        35.87 Mbits/s         301
>>> TCP download::10 :        37.01        35.87 Mbits/s         301
>>> TCP download::11 :        37.02        35.87 Mbits/s         301
>>> TCP download::12 :        37.00        35.87 Mbits/s         301
>>> TCP download::2  :        37.03        35.87 Mbits/s         301
>>> TCP download::3  :        36.99        35.87 Mbits/s         301
>>> TCP download::4  :        37.03        35.87 Mbits/s         301
>>> TCP download::5  :        37.07        35.87 Mbits/s         301
>>> TCP download::6  :        37.00        35.87 Mbits/s         301
>>> TCP download::7  :        37.12        35.87 Mbits/s         301
>>> TCP download::8  :        37.05        35.87 Mbits/s         301
>>> TCP download::9  :        37.03        35.87 Mbits/s         301
>>> ----------------
>>>
>>> Does this suggest that it is indeed a problem of an underpowered CPU in your
>>> case?
>>>
>>> George
>>>
>>>
>>> On Mon, Nov 27, 2017 at 10:53 AM, Pete Heist <peteheist@gmail.com> wrote:
>>>>
>>>>
>>>> On Nov 27, 2017, at 3:48 PM, Jonathan Morton <chromatix99@gmail.com>
>>>> wrote:
>>>>
>>>> It's not at all obvious how we'd detect that.  Packets are staying in the
>>>> queue for less time than the codel target, which is exactly what you'd get
>>>> if you weren't saturated at all.
>>>>
>>>> That makes complete sense when you put it that way. Cake has no way of
>>>> knowing why the input rate is lower than expected, even if it’s part of the
>>>> cause.
>>>>
>>>> I don’t think flent can know this either. It can’t easily know the cause
>>>> for its total output to be lower than expected.
>>>>
>>>> All I know is, this is a common problem in deployments, particularly on
>>>> low-end hardware like ER-Xs, that can be tricky for users to figure out.
>>>>
>>>> I don’t even think monitoring CPU in general would work. The CPU could be
>>>> high because it’s doing other calculations, but there’s still enough for
>>>> cake at a low rate, and there’s no need to warn in that case. I’d be
>>>> interested in any ideas on how to know this is happening in the system as a
>>>> whole. So far, there are just various clues that one needs to piece together
>>>> (no or few drops or marks, less total throughput that expected, high cpu
>>>> without other external usage, etc). Then it needs to be proven with a test.
>>>>
>>>> Anyway thanks, your clue was what I needed! I need to remember to review
>>>> the qdisc stats when something unexpected happens.
>>>>
>>>> _______________________________________________
>>>> Cake mailing list
>>>> Cake@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/cake
>>>>
>>>
>>>
>>> _______________________________________________
>>> Cake mailing list
>>> Cake@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cake
>>>
>>
>>
>>
>> --
>>
>> Dave Täht
>> CEO, TekLibre, LLC
>> http://www.teklibre.com
>> Tel: 1-669-226-2619
>> _______________________________________________
>> Cake mailing list
>> Cake@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cake
>



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619

  reply	other threads:[~2017-11-27 17:38 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-27 11:04 Pete Heist
2017-11-27 11:10 ` Toke Høiland-Jørgensen
2017-11-27 11:12   ` Pete Heist
2017-11-27 12:18     ` Jonathan Morton
2017-11-27 13:05       ` Pete Heist
2017-11-27 14:01         ` Jonathan Morton
2017-11-27 14:07           ` Pete Heist
2017-11-27 14:34             ` Pete Heist
2017-11-27 14:48               ` Jonathan Morton
2017-11-27 15:53                 ` Pete Heist
2017-11-27 16:17                   ` Georgios Amanakis
2017-11-27 17:32                     ` Pete Heist
2017-11-27 17:33                     ` Dave Taht
2017-11-27 17:34                       ` Sebastian Moeller
2017-11-27 17:38                         ` Dave Taht [this message]
2017-11-27 17:50                           ` Pete Heist
2017-11-27 17:35                       ` Pete Heist
2017-11-27 18:13     ` Dave Taht
2017-11-27 18:21       ` Pete Heist
2017-11-27 18:45 ` Pete Heist
2017-11-27 19:06   ` Georgios Amanakis
2017-11-27 20:37   ` Toke Høiland-Jørgensen
2017-11-27 20:50     ` Dave Taht
2017-11-27 20:53     ` Pete Heist
2017-11-27 21:08       ` Toke Høiland-Jørgensen
2017-11-27 21:17         ` Pete Heist

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=CAA93jw6n+MUAT6KVnyJ4fSg9jiWBB9qLiMRzHW8LkwKE2kEgrQ@mail.gmail.com \
    --to=dave.taht@gmail.com \
    --cc=cake@lists.bufferbloat.net \
    --cc=gamanakis@gmail.com \
    --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