From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from au-smtp-delivery-112.mimecast.com (au-smtp-delivery-112.mimecast.com [124.47.189.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 1FB4F3B29E for ; Thu, 16 Jul 2020 21:16:40 -0400 (EDT) Received: from AUS01-SY3-obe.outbound.protection.outlook.com (mail-sy3aus01lp2053.outbound.protection.outlook.com [104.47.117.53]) (Using TLS) by relay.mimecast.com with ESMTP id au-mta-42-dKmbQeakN0Sx1xSSQQAgTQ-1; Fri, 17 Jul 2020 11:16:20 +1000 X-MC-Unique: dKmbQeakN0Sx1xSSQQAgTQ-1 Received: from ME2PR01MB3907.ausprd01.prod.outlook.com (2603:10c6:220:24::18) by MEAPR01MB2808.ausprd01.prod.outlook.com (2603:10c6:201:f::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.21; Fri, 17 Jul 2020 01:16:18 +0000 Received: from ME2PR01MB3907.ausprd01.prod.outlook.com ([fe80::4ce9:5a87:9ede:1c60]) by ME2PR01MB3907.ausprd01.prod.outlook.com ([fe80::4ce9:5a87:9ede:1c60%6]) with mapi id 15.20.3174.025; Fri, 17 Jul 2020 01:16:18 +0000 To: bloat@lists.bufferbloat.net References: <156954CF-BCBC-4B0C-9C42-A2A6F2450185@gmail.com> From: grenville armitage Message-ID: <446af9fe-c06b-3be9-e1fb-4157dafb481e@swin.edu.au> Date: Fri, 17 Jul 2020 11:16:17 +1000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 In-Reply-To: <156954CF-BCBC-4B0C-9C42-A2A6F2450185@gmail.com> Content-Language: en-US X-ClientProxiedBy: ME2PR01CA0194.ausprd01.prod.outlook.com (2603:10c6:220:34::14) To ME2PR01MB3907.ausprd01.prod.outlook.com (2603:10c6:220:24::18) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from gjaflix.space4me.com (121.200.16.62) by ME2PR01CA0194.ausprd01.prod.outlook.com (2603:10c6:220:34::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.17 via Frontend Transport; Fri, 17 Jul 2020 01:16:17 +0000 X-Originating-IP: [121.200.16.62] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 3bf07af9-69d7-4c88-8f31-08d829ef01f6 X-MS-TrafficTypeDiagnostic: MEAPR01MB2808: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: JxdZVZnPCB9ppPJ+7ygzTUMD09Y4eLjod37ViLBUZh4l4vKE152NEG58W7pWGqA3YG6wPgRK/zxilF/jjPEjIGYZzertPcoRGSjQSWugFngeAmTYSNQvpH5jLTcExj8BJAMC6Kp6Uj3hVaVxUekCx+3LBKxxydqdQXcMRA5BWgWcAwN6etgLqzgdOo/KN86ka+HT4kjFqVxE1OlUy5bm5bLItwGpmTQ26vACUu6X0vg2PnEY7szwd9GCxuKqQ210dm0wfuQApb/cydAHHv3f44cIva95DahcE6t+eDDQyHNDgSFImKyPnMfGnNQMP+E+FMIlOrMxjKcRPOyYdcee4SUqYotPN2vmSao9zdUJdl6cXum+pVRtd3//JtuZsR/ZJIkk8L7nU0MM1WbtYtwBCJT5sT2ECqxPg5bqBvNFUKyBti2bMhYtl5YqYNw+K069EMWtqZEyT24bH7ncc52jyw== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:ME2PR01MB3907.ausprd01.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(346002)(136003)(396003)(376002)(366004)(8936002)(52116002)(66556008)(31686004)(31696002)(6506007)(6512007)(36756003)(6916009)(5660300002)(6486002)(66946007)(966005)(8676002)(2616005)(53546011)(786003)(956004)(2906002)(316002)(66476007)(16526019)(26005)(478600001)(186003)(166002)(86362001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: DPkaUJ5OO8A0wE+svwnCJPciRO+97Z6M4RYz5aN9EYwGaQiZ23aScn+5m+M5F3uD4M34olFoPbeau4hyesfzUbW3Rk4x1HQ21IxWoqzCDSBfAgu7hnyGXThF1OdLkzUwWQVifOfB7I8sPp+Ixd+6voE9gCe+PzEtfH9hDdddQvtuJ/jULx1BxqUBjXjdG0Heo2PP5X9t6qKRWMxyei1w6OYbRNZDjCsvblDNrt02CTClvjzlLjcMumj8JZ/DL4q/0cmA5aTtDCAMZDPN5oLSvhY3qfEYFyGzI3n/6IdT3b5+sZjYgJHjPM1lD7ZJeP2tRdZb5PnuJhf83jqHYKxSne0WRLNoffyQDhmBJ+DQ+A22rc6DW5+dLwVbPhvRpoS4s3JXJHibSt8mtpdIuHPGUDWlhKfus5uC4yw5NVUaQfa5xoqh2sFlDb/ijxOu4iMLmcHjzzvwTGj/C8j4FwUXjv0miTcWHZcLAbExJZCxkF0= X-OriginatorOrg: swin.edu.au X-MS-Exchange-CrossTenant-Network-Message-Id: 3bf07af9-69d7-4c88-8f31-08d829ef01f6 X-MS-Exchange-CrossTenant-AuthSource: ME2PR01MB3907.ausprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jul 2020 01:16:18.1062 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: df7f7579-3e9c-4a7e-b844-420280f53859 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: cLc0h/K7pfA88O5+SG1RHc62V4QVV9xYa70iqwp8hSmuCt+4tRiSLDH8E6nV1Wjp3VOTfo2xKvlLdzaGmQlVFw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MEAPR01MB2808 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: swin.edu.au Content-Type: multipart/alternative; boundary="------------02DEBCDA9C1F11FE6F0257F8" Subject: [Bloat] fq_pie in FreeBSD... Re: Phoronix: Linux 5.9 to allow FQ_PIE as default X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 01:16:41 -0000 --------------02DEBCDA9C1F11FE6F0257F8 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable A tangent for anyone who is running a FreeBSD-based gateway, there's also a= n fq_pie in dummynet (https://reviews.freebsd.org/rS300779). I haven't play= ed with it for a long time, but still curious if anyone's experimented with= that combination. (Particularly if the on-the-wire behavior differs from t= hat of linux fq-pie.) cheers, gja On 2020-07-16 10:37, Jonathan Morton wrote: > > On 16 Jul, 2020, at 12:58 am, Michael Yartys via Bloat wrote: > > > > Are there any major differences between fq_codel and fq_pie in terms of= their performance? > > I think some tests were run some time ago which showed significantly bett= er behaviour by fq_codel than fq_pie. In particular, the latter used only a= single AQM instead of an independent one for each flow. I'm not sure wheth= er it's been changed since then. > > The only advantage I can see for PIE over Codel is, possibly, a reduction= of system load for use of the AQM. But fq_codel is already pretty efficien= t so that would be an edge case. > > In any case, it is already possible to chose any qdisc you like (with def= ault parameters) as the default qdisc. I'm really not sure what the fuss is= about. > > > And how does the improved fq_codel called cobalt, which is used in cake= , stack up? > > COBALT has some modifications to basic Codel which, I think, could profit= ably be backported into fq_codel. It also has a particular extra mode, base= d on BLUE, for dealing with unresponsive traffic (that continued to build q= ueue even after lots of ECN signalling and/or Cdel-scheduled packet drops).= It is the latter which inspired the name. > > For the other major functional component of fq_codel, Cake also has a set= -associative hash function for allocating flows into queues, which substant= ially reduces the probability of hash collisions in most cases. > > - Jonathan Morton > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat --------------02DEBCDA9C1F11FE6F0257F8 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
A tangent for anyone who is running a FreeBSD-based gateway, there's also an fq_pie in dummynet (https://reviews.freebsd.org/rS300779<= /a>). I haven't played with it for a long time, but still curious if anyone's experimented with that combination. (Particularly if the on-the-wire behavior differs from that of linux fq-pie.)

cheers,
gja

On 2020-07-16 10:37, Jonathan Morton wrote:
=20 > On 16 Jul, 2020, at 12:58 am, Michael Yartys via Bloat <bloat@lists.bufferbloat.net> wrote:
>
> Are there any major differences between fq_codel and fq_pie in terms of their performance?

I think some tests were run some time ago which showed significantly better behaviour by fq_codel than fq_pie. In particular, the latter used only a single AQM instead of an independent one for each flow. I'm not sure whether it's been changed since then.

The only advantage I can see for PIE over Codel is, possibly, a reduction of system load for use of the AQM. But fq_codel is already pretty efficient so that would be an edge case.

In any case, it is already possible to chose any qdisc you like (with default parameters) as the default qdisc. I'm really not sure what the fuss is about.

> And how does the improved fq_codel called cobalt, which is used in cake, stack up?

COBALT has some modifications to basic Codel which, I think, could profitably be backported into fq_codel. It also has a particular extra mode, based on BLUE, for dealing with unresponsive traffic (that continued to build queue even after lots of ECN signalling and/or Cdel-scheduled packet drops). It is the latter which inspired the name.

For the other major functional component of fq_codel, Cake also has a set-associative hash function for allocating flows into queues, which substantially reduces the probability of hash collisions in most cases.

- Jonathan Morton
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

--------------02DEBCDA9C1F11FE6F0257F8--