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
>>
next prev parent 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