From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 6754E3B2A4; Mon, 23 Jul 2018 08:52:26 -0400 (EDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 6656CB4; Mon, 23 Jul 2018 14:52:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1532350344; bh=hzx7eL8jpERzzUCsHGRD5u3e31T6FLDkn7mEfdp+qm8=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=knR9Ezx82u+LrE0LWA6JY/BQR+zQJ/TXg58ShLucT+4Blvb2Mt2r2sUC0wFmzpCjg wtIq2DnHtfAmKkXwwnMQ5RsBeehbY3rv5tk7AAown6TADIMHaqUoPvxPG58CAVwz+/ 2SGkekvSlwnnpEdrWclJPjLd7BORPKPLLFddCFac= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 64757B3; Mon, 23 Jul 2018 14:52:24 +0200 (CEST) Date: Mon, 23 Jul 2018 14:52:24 +0200 (CEST) From: Mikael Abrahamsson To: Jonathan Morton cc: Luca Muscariello , Cake List , make-wifi-fast@lists.bufferbloat.net, bloat In-Reply-To: <1A06B0BB-4B2F-4E94-B947-EF41BCC3F18C@gmail.com> Message-ID: References: <1A06B0BB-4B2F-4E94-B947-EF41BCC3F18C@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Re: [Make-wifi-fast] [Bloat] Van Jacobson's slides on timing wheels at netdevconf X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 12:52:26 -0000 On Sat, 21 Jul 2018, Jonathan Morton wrote: > An example of such a situation would be sparse flows in DRR++, which is > a key part of fq_codel and Cake. So to implement DRR++ using timing > wheels, you have to choose your scheduling horizon carefully so as to > minimise the delay to sparse packets. At the spring IETF, there was talk from IEEE person about using ethernet pause frames to get senders to stop talking for a while. My understanding was that this was on microsecond scale or even nanosecond time scales. One of the mentions in the presentation was on slide 10 about "fat-buffered router". In the data center, these are kind of going away, because on-die memory is small and rates are high. A 64x100GE forwarding asic might have 16MB of buffer, which is very little buffer for the kind of bit rates we're talking here. https://www.youtube.com/watch?v=sJMvAqEQCBE 1h44m in (proposed IEEE 802.1Qcz work) is the one I am thinking of. Wonder how this would interact with the timing wheel proposed by Van Jacobson? -- Mikael Abrahamsson email: swmike@swm.pp.se