From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 2B0633B2A4 for ; Wed, 15 Nov 2017 15:04:27 -0500 (EST) Received: from nemesis.taht.net (c-24-6-113-161.hsd1.ca.comcast.net [24.6.113.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id D4B4B21474; Wed, 15 Nov 2017 20:04:25 +0000 (UTC) From: Dave Taht To: Pete Heist Cc: cake@lists.bufferbloat.net References: <87vaic8vv1.fsf@nemesis.taht.net> <87bmk372du.fsf_-_@nemesis.taht.net> Date: Wed, 15 Nov 2017 12:04:24 -0800 In-Reply-To: <87bmk372du.fsf_-_@nemesis.taht.net> (Dave Taht's message of "Wed, 15 Nov 2017 11:44:45 -0800") Message-ID: <87375f71h3.fsf@nemesis.taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] Cake upstream Planning X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 20:04:27 -0000 Dave Taht writes: >> >> TCP RTT ~=3D 8ms with default qdisc, throughput ~=3D 940 Mbit >> TCP RTT ~=3D 4.5ms with =E2=80=98cake unlimited=E2=80=99, throughput ~= =3D 920 Mbit >> TCP RTT ~=3D 1ms with =E2=80=98cake unlimited lan=E2=80=99, throughput ~= =3D 920 Mbit This was with BQL in play? Monitoring BQL's behavior might help. I'd also love to know an exact setting for the shaper as a close as possible to the underlying bandwidth of ethernet. However, I tend to be plagued with >> >> So yes, we can lower TCP RTT with these more aggressive settings. But ju= st to >> make sure, we=E2=80=99re confident that there are no other side effects = from these lower >> targets and intervals? Is there anything else I should test for to be su= re? For >> example, when I rate limit to 950 Mbit and try the same test above, =E2= =80=98lan=E2=80=99 causes >> a 20% drop in throughput vs the defaults. That may be from an overtaxed = CPU, but >> I don=E2=80=99t know. I also wonder how this affects routed vs local tra= ffic. I=E2=80=99ll try >> to test this at some point, as I want to understand it better anyway to = know how >> backhaul links should be configured... One interesting thing that might make tcp behave better is the new pacing code which lets us set pacing to a different log value. Presently - at 10 - the TSQ algorithm recalculates things at 1ms. The pacing value is intended to be changed to, say, 6 or 7 to make wifi work better... and I suspect, that if it were upped to, say 12 (250us), on ether= net, that might make pacing more effective there. Just like breaking the sound barrier, breaking the 1ms barrier looks to be hard within conventional kernel thread scheduling. >> >> Non-Blockers: >>=20=20=20=20=20 >> * I don't believe in cobalt, or rather, I won't believe in it until = we >> have data at many RTTs. That said, what I'd propose would be a >> monolithic cobalt.h file rather than codel5.h. >>=20=20=20=20=20 >> The netns stuff will make simulating RTTs and bandwidths much easier= =E2=80=A6. >> >>=20=20=20=20=20 >> * I think the fq_codel batch drop facility is better than what cake = uses >> in case of floods. Partially due to the need to handle backports the >> mechanism fq_codel uses is hard to use - but going mainline we could= add >> this. >>=20=20=20=20=20 >> * The autorate_ingress code should be marked experimental. I keep ho= ping >> it can be improved by better looking for "smoothness" inbound, but >> algorithms escape me. This doesn't bother me much, as tcp continues = to >> be improved over the past 50 years, perhaps we can find ways to impr= ove >> this with more users. >>=20=20=20=20=20 >> * It is possible to tune the quantum and peeling functions to not pe= el >> to the extent they do. Particularly there is usually no need (aside = from >> wanting accurate statistics) to peel below 1500 bytes (except perhaps >> with the new ack filter mode). We experimented a lot with this in the >> early days but could never come to a resolution. >>=20=20=20=20=20 >> * I don't have any use for precidence mode and would like to remove = it. >> >> Regarding non-blockers, for FreeNet=E2=80=99s purposes, I wanted to see = if I could add >> the option to use packet marks as one of the identifiers for host isolat= ion, but >> I=E2=80=99ve not had time to explore it yet. This would be helpful for I= SPs that want to >> ensure fairness when there isn=E2=80=99t a one-to-one mapping between IP= address and >> customer. I=E2=80=99ll see if I can at least try it. > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake