Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: moeller0 <moeller0@gmx.de>
To: "Dave Täht" <dave.taht@gmail.com>
Cc: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>,
	Jonathan Morton <chromatix99@gmail.com>,
	cake@lists.bufferbloat.net
Subject: Re: [Cake] second system syndrome
Date: Mon, 21 Dec 2015 12:10:26 +0100	[thread overview]
Message-ID: <95560E7E-DEAF-40D8-B704-CEA38A0CDE62@gmx.de> (raw)
In-Reply-To: <CAA93jw6NN2vWRjuB46eL69_tQqhBvLAvA8nAeH0TyYhiU1TsyQ@mail.gmail.com>

Hi Dave,


> On Dec 21, 2015, at 11:40 , Dave Taht <dave.taht@gmail.com> wrote:
> 
> On Mon, Dec 21, 2015 at 10:02 AM, moeller0 <moeller0@gmx.de> wrote:
>> I had a quick look over these, both htb+fq_codel egress and bcake egress (both without perf) seem “contaminated" by a periodic process with a period of 50/8 = 6.25 seconds. Is this one of the cyclic probes measuring cpu load or so?
>>        BTW are you using simplest.qos or simple.qos for the htb+fq_codel test (or something unrelated to sqm)? I ask because we have a shipload of costly iptables/tc filter stuff only happening in simple.qos (while rural_be will not use any DSCPs besides 0 the filters should still cost a bit CPU). I do not seem to be able to see any additional meta information from the flent files, probably PEBCAK n my side...
> 
> simple.qos.

	Excellent, thanks for the information.

> 
> see also: https://github.com/dtaht/sch_cake/commit/a66ee4fa355a62633b34fd05834075ea294e3b79

	Don’t get me wrong I am always duly impressed by making things more efficient, but without actually looking at the code I would believe this is only called if a new diffserv regime is initialized? And if the initialization would take "a minute" I could not care less (for the same reason I am not sure why "target = interval >> 4” is such a big deal computationally wise; I understand its charm in getting rid of target as an explicit variable though).

> 
> Did not switch cake over to it...
> 
> I still do not see any reason for precedence or diffserv8 to exist,
> and can barely cope with the idea of diffserv4.

	This is all beyond my "pay-grade”/area of expertise, but… 

	You convinced me long ago, that next to best-effort, it would be nice to have a way of saying packets are more or less important, so this is 3 tiers right there and exactly what we have in simple.qos. But it turns out packets, like animals I might add, are not all equal (and  the simple “Four legs good, two legs bad” dichotomy is not sufficient either ;) ) some are just special and that need special care: in case of PPPoE-links all PPP administrative packets need* a priority above all else  as do yet to be coded ICMP latency under load probes. And since 3+1 equals 4, I will go and build a new DSCP3plus1.qos script (once I get around to it ;) ) (<Note to self>, since VoIP is the best candidate for elevated priority, make sure to scale this tier for an integer number of VoIP flows (which clock in at around 100Kbps each) and make this tier symmetric, do not scale ingress and egress differently in the same ratio as the link asymmetry; also tier 4 does not need to be exposed to client machines at all, this is an affair between the router and its uplink</Note to self>)

Diffserv8 and precedence I have no real opinion on; except that in my personal pet theory of DSCP best practices there are only three bit available anyway. (I lifted this idea from  or better "got inspired by"  one of the RFCs cited on one of the bufferbloat lists, so I do not claim originality at all). So a scheme with 8 tiers would be “complete”, not that this justifies additional complexity…

Best Regards
	Sebastian

*: actually work best with, not "will not work with out" highest priority)


> 
>> 
>> Best Regards
>>        Sebastian
>> 
>> 
>>> On Dec 20, 2015, at 13:52 , Dave Taht <dave.taht@gmail.com> wrote:
>>> 
>>> the 200/20mbit tests I ran yesterday.
>>> 
>>> http://snapon.cs.kau.se/~d/ptests/
>>> _______________________________________________
>>> Cake mailing list
>>> Cake@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cake
>> 


  reply	other threads:[~2015-12-21 11:10 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-06 14:53 Dave Taht
2015-12-06 16:08 ` Sebastian Moeller
2015-12-07 12:24   ` Kevin Darbyshire-Bryant
2015-12-20 12:47     ` Dave Taht
2015-12-20 12:52       ` Dave Taht
2015-12-21  9:02         ` moeller0
2015-12-21 10:40           ` Dave Taht
2015-12-21 11:10             ` moeller0 [this message]
2015-12-21 12:00               ` Dave Taht
2015-12-21 13:05                 ` moeller0
2015-12-21 15:36                   ` Jonathan Morton
2015-12-21 18:19                     ` moeller0
2015-12-21 20:36                       ` Jonathan Morton
2015-12-21 21:19                         ` moeller0
     [not found]                         ` <8737uukf7z.fsf@toke.dk>
2015-12-22 15:34                           ` Jonathan Morton
2015-12-22 22:30                     ` Kevin Darbyshire-Bryant
2015-12-23 11:43                       ` Dave Taht
2015-12-23 12:14                         ` Kevin Darbyshire-Bryant
2015-12-23 12:27                         ` Jonathan Morton
2015-12-23 12:41                           ` Dave Taht
2015-12-23 13:06                             ` Jonathan Morton
2015-12-23 14:58                               ` Dave Taht
2015-12-20 13:51       ` moeller0
2015-12-06 18:21 ` 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=95560E7E-DEAF-40D8-B704-CEA38A0CDE62@gmx.de \
    --to=moeller0@gmx.de \
    --cc=cake@lists.bufferbloat.net \
    --cc=chromatix99@gmail.com \
    --cc=dave.taht@gmail.com \
    --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