Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: Sebastian Moeller <moeller0@gmx.de>
To: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>
Cc: "cake@lists.bufferbloat.net" <cake@lists.bufferbloat.net>
Subject: Re: [Cake] cake target corner cases?
Date: Mon, 2 Nov 2015 12:23:13 +0100	[thread overview]
Message-ID: <631AA4E6-6447-4E0D-9CA4-5500E1263CF5@gmx.de> (raw)
In-Reply-To: <AC22FB4A-355D-4F51-B356-7D83F38182B0@darbyshire-bryant.me.uk>

Hi Kevin,

On Nov 1, 2015, at 22:52 , Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> wrote:

> 
> Can't give full explanation now but the bytes per ns calculation which is used as a basis for target on 'slow' links uses mtu*1.5

	Which has the advantage of being larger than ATM encapsulation expansion would account for so this is on the safe side…

Best Regards
	Sebastian

> 
> --
> Cheers,
> 
> Kevin@Darbyshire-Bryant.me.uk
> 
>> On 1 Nov 2015, at 20:58, Alan Jenkins <alan.christopher.jenkins@gmail.com> wrote:
>> 
>>> On 01/11/2015, Sebastian Moeller <moeller0@gmx.de> wrote:
>>> Dear cake committee,
>>> 
>>> I just played around with the most recent sch_cake and noticed us:
>>> 
>>> user@computer:~/CODE/tc-adv/tc> sudo tc-adv qdisc del dev eth0 root
>>> user@computer:~/CODE/tc-adv/tc> sudo tc-adv qdisc replace dev eth0 root cake
>>> bandwidth 1Mbit ; sudo tc-adv -s qdisc
>>> qdisc cake 8005: dev eth0 root refcnt 6 bandwidth 1Mbit diffserv4 flows rtt
>>> 100.0ms raw
>>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
>>> backlog 0b 0p requeues 0
>>> capacity estimate: 1Mbit
>>>            Tin 0       Tin 1       Tin 2       Tin 3
>>> thresh       1Mbit   937504bit     750Kbit     250Kbit
>>> target      18.2ms      19.4ms      24.2ms      72.7ms
>>> interval     145.3ms     155.0ms     193.8ms     581.4ms
>> 
>> 
>>> Here target is always 12.5% of interval instead of the expected 6.25%
>>> 1/16 = 0.0625
>>> 72.7/581.4 = 0.125042999656
>>> 24.2/193.8 = 0.124871001032
>>> 19.4/155.0 = 0.125161290323
>>> 18.2/145.3 = 0.125258086717
>>> But the bandwidth is really low, so pushing target closer to the bandwidth
>>> conserving side of the codel rationale might be fine,
>> 
>> Pretty sure it's a minimum derived from the MTU
>> 
>> ((mtu=1.5kbyte) * 8 bits/byte) / 1000 Mbit/s = 0.012s
>> 
>> except I don't know where the .5 comes from, that's incredibly
>> suspicious to have a round 1/8th :).
>> 
>> The point is that if buffering falls below the MTU, the connection
>> will be completely clobbered.
>> 
>> In a way it's nice cake reports this in the target.  Otherwise cake
>> would claim the target is 5ms, but measurements would show the
>> effective target is more than twice as high.
>> 
>>> since latency is bad
>>> to begin with and bandwidth also pretty scarce. But it might be interesting
>>> to do a few more measurements at low bandwidths to confirm that the 12.5% of
>>> interval logic holds water; one could also argue that people with such links
>>> (a lot of DSL lines have even less upload, so this certainly is not extreme)
>>> might think that any added ms of delay matters (more than bandwidth);
>>> currently we leave the user no remedy...
>>> 
>>> 
>> 
>> <snip>
>> 
>>> This looks okay, except Tin3 has target at 7.3/101.0 = 0.0722772277228 7% of
>>> interval.
>> 
>> Looks like the same thing.
>> 
>> 
>>> Both observations might actually be on purpose, but if so we should document
>>> that behavior as expected, for example in the man page…
>>> 
>>> Best Regards
>>>   Sebastian
>> 
>> 
>> I'm afraid I can't help mention my old niggle :).  _If_ you mention
>> this alongside instructions for RRUL, I think you'd also want to
>> explain^W mention the measurement increase for diffserv4 v.s.
>> besteffort.
>> 
>> I think the ICMP ping measurement increases by another 10ms on my
>> connection (11500k down /  850k up, so an mtu is ~15ms).  I concluded
>> it was inherent in prioritization.  Now I guess it's equal to the sum
>> of target * bandwidth_fraction for each class "above" icmp ping (and
>> could be tested).
>> 
>> I have graphs from sqm with and without classification.  I did test
>> cake once and I think it's the same (otherwise would be a bug).
>> 
>> https://dl.dropboxusercontent.com/u/49925445/bufferbloat.net/220-cdf-531414.sqm_simplest_11500_850_atm40_udppingfix.svg
>> 
>> https://dl.dropboxusercontent.com/u/49925445/bufferbloat.net/221-cdf-360505.sqm_simple_11500_850_atm40_udppingfix.svg
>> 
>> Warm regards
>> Alan
>> _______________________________________________
>> Cake mailing list
>> Cake@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cake


  parent reply	other threads:[~2015-11-02 11:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-01 18:07 Sebastian Moeller
2015-11-01 20:58 ` Alan Jenkins
2015-11-01 21:52   ` Kevin Darbyshire-Bryant
2015-11-02  0:20     ` Alan Jenkins
2015-11-02 11:17       ` Sebastian Moeller
2015-11-02 16:20         ` Alan Jenkins
2015-11-02 18:49           ` Sebastian Moeller
2015-11-02 20:38             ` Alan Jenkins
2015-11-02 11:23     ` Sebastian Moeller [this message]
2015-11-02 11: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=631AA4E6-6447-4E0D-9CA4-5500E1263CF5@gmx.de \
    --to=moeller0@gmx.de \
    --cc=cake@lists.bufferbloat.net \
    --cc=kevin@darbyshire-bryant.me.uk \
    /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