From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id B7BEB3B2A4 for ; Wed, 9 Mar 2022 12:25:03 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1646846703; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=yIkAzwIz8baTd3Sqbb+CA+3OHXI6udps64VEAZu+Qog=; b=GYttHcdSLgi3nt5iq4vR3bGpDfWkbI1pKrJahpTuJ71dU5IfReuAUNzBRkKMqHEN+XbZPO QTqp+xW4yZ1SjVBcGEkvzPSdD07xUouQlyP00kGiXi8IggmUWMjWKSEbK6WW3ebVzFbMJA dZMW1GgscTEDLS0D1NbarHtueR6Mh8k= Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-14-AJpfxfsqOxOJFaQ7UUPufQ-1; Wed, 09 Mar 2022 12:25:01 -0500 X-MC-Unique: AJpfxfsqOxOJFaQ7UUPufQ-1 Received: by mail-ed1-f71.google.com with SMTP id b9-20020aa7d489000000b0041669cd2cbfso1638195edr.16 for ; Wed, 09 Mar 2022 09:25:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:date:mime-version:user-agent:cc :subject:content-language:to:references:in-reply-to :content-transfer-encoding; bh=yIkAzwIz8baTd3Sqbb+CA+3OHXI6udps64VEAZu+Qog=; b=2jJG0xWh3aocyUWCRY7Vsd/XZtcbYzuEXT3dWXOJ+aqj+kmT0hd4b1Nsjb7jC4QDOb 5Iyc1alnj+eWpf6A+A95HoS/wHkBI3RoBw0Y7j8ol9Hg6CFriMg8eNCCuk5UCr8thkF7 gT9Jixm88kO34SEK2jS5rxZ5U4dM5PohLyISVDtMLYlYRRLtJEoh2vhOU3lq8uwIdGSz SkhJv4sgkXuIBWAy9mZMuSLr/3YcS0hKxwOypemqX3h6h2lPHapKi+bZVyJsJUJg7EMv Jucy39uZZpPastmTWTk2ncWPKIijjFAtBtlrWVmTH6fEgO43EXr1y+tOjrpY6Icvi+qE JZOQ== X-Gm-Message-State: AOAM531Oaady1MqnuqmQBuwE5QMPhBBUKvEOJUkPyJcAb2g1WBVQdiOn frFDOPvHJyi9txOng0/jPt+4dxz8FkchWKTMrYqDX3TtQtbHwd5xmaYoASMpZTMjXIaqn9t3tSW t1oMWXsQW6vtmyPr08xSHY8I= X-Received: by 2002:a17:906:6150:b0:6db:1bd8:f499 with SMTP id p16-20020a170906615000b006db1bd8f499mr767841ejl.424.1646846700120; Wed, 09 Mar 2022 09:25:00 -0800 (PST) X-Google-Smtp-Source: ABdhPJw9bGZCT5MIIlmQ24Cdu/+g/HZOJ9hNiZue25PYnilLzLbFq9P6ikeBo9zOlHcic3iIX7bE1Q== X-Received: by 2002:a17:906:6150:b0:6db:1bd8:f499 with SMTP id p16-20020a170906615000b006db1bd8f499mr767816ejl.424.1646846699841; Wed, 09 Mar 2022 09:24:59 -0800 (PST) Received: from [192.168.0.50] (87-59-106-155-cable.dk.customer.tdc.net. [87.59.106.155]) by smtp.gmail.com with ESMTPSA id i21-20020a1709061cd500b006da62ab503csm940303ejh.157.2022.03.09.09.24.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Mar 2022 09:24:58 -0800 (PST) From: Jesper Dangaard Brouer X-Google-Original-From: Jesper Dangaard Brouer Message-ID: <9785d2cd-b164-deb4-4cbe-7d0fb356f16e@redhat.com> Date: Wed, 9 Mar 2022 18:24:57 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 To: =?UTF-8?Q?Toke_H=c3=b8iland-J=c3=b8rgensen?= , Michael Menth , bloat References: <87y21julxu.fsf@toke.dk> In-Reply-To: <87y21julxu.fsf@toke.dk> Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=jbrouer@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Bloat] Up-to-date buffer sizes? 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: Wed, 09 Mar 2022 17:25:03 -0000 On 09/03/2022 17.31, Toke Høiland-Jørgensen via Bloat wrote: > Michael Menth writes: > >> Hi all, >> >> are there up-to-date references giving evidence about typical buffer >> sizes for various link speeds and technologies? > > Heh. There was a whole workshop on it a couple of years ago; not sure if > it concluded anything: http://buffer-workshop.stanford.edu/program/ > > But really, asking about buffer sizing is missing the point; if you have > static buffers with no other management (like AQM and FQ) you're most > likely already doing it wrong... :) Exactly, I agree with Toke. The important parameter is the latency. Or the packet sojourn time (rfc8289 + rfc8290) observed waiting in the queue. The question you should be asking is: - What is the max queue latency I'm "willing" to experience on this link? Hint, you can then depending on the link rate calculate the max buffer size you should configure. The short solution is: - just use fq_codel (rfc8290) as the default qdisc. --Jesper