From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 77C4E3B2A3 for ; Fri, 28 Apr 2017 19:52:39 -0400 (EDT) Received: by mail-wm0-x22b.google.com with SMTP id u65so53640346wmu.1 for ; Fri, 28 Apr 2017 16:52:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=yi9YnteX/tPaj5wIe23kIxKiQ3AuYCU4TquC6FFJtVE=; b=XPKGwdNZc6UVb6Rsx+rSYNwgosIXOKrn+gCjFhjACp3UHGUTW1Dk77J+btTjOrRHFa GTzggYgXM5qyG6Cb6d20RPaIXBwR7tfCAhU09RmiCjUOgVzwvrFgHlEMdlAjXCIlSKVd ZnsWw5zYp3wkymVZ8L8YBid9WP4Xvy64LwzwxzZUetI1r59y3j5y97kdggoPdo4GMTmJ PhuWqQi1n1VPoKQoIq5yqbJGafQJAe0TS7rZ8CytNXhmxegSjaIdD9s4AG5T1Py+vT+m RiqTtCO7eNPJS6XyTgf/jiKUIoNl1q0DNzbD3VakZgSfnFgDe9XHpShJGe7FXpWUjLKG QODw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=yi9YnteX/tPaj5wIe23kIxKiQ3AuYCU4TquC6FFJtVE=; b=prShQNuIeQXUOUwvFLMXdX4BfyGpIv+QpZHREgUakavjh1988hb3Vc/MX2zbOREgyy NmOU3AHYXEA4otN7GBAceUGgQ7KxqG++0dXzkaKsYgUciuWWLGMTMHBaj+/2p7dSJm5W f3tkNULy9tx6OvJ+9BFSmyD1WtkFMaxNa7deBvzTkPrSJltMM0Fbobies2cW5e9PVLEf 8FYBifGc9dOcwsPfcN+4utSV9+bSDKue5g+j+wlYn1DnCXvUAI/UmLdr4JTsTHaSfnrx 8dkVIuOljM5MTh1+1QS05dzXPX8ppv2ZNE8KLuC9dF53IR1hso64Nx6HCdbV9+shYmih iheg== X-Gm-Message-State: AN3rC/5BnVVifUStXmRtFLahHTMsoDN/4dXYu70rSi0x8mJprDo6XMUw nkV0We8BGjNAdg== X-Received: by 10.28.206.2 with SMTP id e2mr381456wmg.3.1493423558004; Fri, 28 Apr 2017 16:52:38 -0700 (PDT) Received: from [192.168.0.3] (185.182.7.51.dyn.plus.net. [51.7.182.185]) by smtp.gmail.com with ESMTPSA id w126sm887290wmb.25.2017.04.28.16.52.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Apr 2017 16:52:37 -0700 (PDT) From: Andy Furniss To: xnor , David Lang Cc: Cake@lists.bufferbloat.net References: <85386ca9-f0be-f60f-796a-e5aa3b8ee212@gmail.com> Message-ID: <5ca09d5c-e674-110a-72e4-b8fd434c7a5d@gmail.com> Date: Sat, 29 Apr 2017 00:52:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0 SeaMonkey/2.51a2 MIME-Version: 1.0 In-Reply-To: <85386ca9-f0be-f60f-796a-e5aa3b8ee212@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Cake] cake default target is too low for bbr? 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: Fri, 28 Apr 2017 23:52:39 -0000 Andy Furniss wrote: >> b) it reacts to increase in RTT. An experiment with 10 Mbps >> bottleneck, 40 ms RTT and a typical 1000 packet buffer, increase in >> RTT with BBR is ~3 ms while with cubic it is over 1000 ms. > > That is a nice aspect (though at 60mbit hfsc + 80ms bfifo I tested with > 5 tcps it was IIRC 20ms vs 80 for cubic). I deliberately test using ifb > on my PC because I want to pretend to be a router - IME (OK it was a > while ago) testing on eth directly gives different results - like the > locally generated tcp is backing off and giving different results. I retested this with 40ms latency (netem) with hfsc + 1000 pfifo on ifb. 5 tcps netperf bbr = 64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=40.611 ms 64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=162.566 ms 64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=163.854 ms 64 bytes from 192.168.0.1: icmp_seq=5 ttl=64 time=143.220 ms 64 bytes from 192.168.0.1: icmp_seq=6 ttl=64 time=139.458 ms 64 bytes from 192.168.0.1: icmp_seq=7 ttl=64 time=139.466 ms 64 bytes from 192.168.0.1: icmp_seq=8 ttl=64 time=139.570 ms 64 bytes from 192.168.0.1: icmp_seq=9 ttl=64 time=139.876 ms 64 bytes from 192.168.0.1: icmp_seq=10 ttl=64 time=139.592 ms 64 bytes from 192.168.0.1: icmp_seq=11 ttl=64 time=139.580 ms 64 bytes from 192.168.0.1: icmp_seq=12 ttl=64 time=139.458 ms 64 bytes from 192.168.0.1: icmp_seq=13 ttl=64 time=40.625 ms Of course cubic was totally horrible - 64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=40.605 ms 64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=209.066 ms 64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=261.172 ms 64 bytes from 192.168.0.1: icmp_seq=5 ttl=64 time=316.063 ms 64 bytes from 192.168.0.1: icmp_seq=6 ttl=64 time=363.004 ms 64 bytes from 192.168.0.1: icmp_seq=7 ttl=64 time=417.586 ms 64 bytes from 192.168.0.1: icmp_seq=8 ttl=64 time=569.068 ms 64 bytes from 192.168.0.1: icmp_seq=9 ttl=64 time=784.740 ms 64 bytes from 192.168.0.1: icmp_seq=10 ttl=64 time=1064.652 ms 64 bytes from 192.168.0.1: icmp_seq=12 ttl=64 time=1204.801 ms 64 bytes from 192.168.0.1: icmp_seq=13 ttl=64 time=973.802 ms 64 bytes from 192.168.0.1: icmp_seq=14 ttl=64 time=155.116 ms 64 bytes from 192.168.0.1: icmp_seq=15 ttl=64 time=40.414 ms With hfsc on root of eth both cubic and bbr were the same - 64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=40.619 ms 64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=52.775 ms 64 bytes from 192.168.0.1: icmp_seq=5 ttl=64 time=53.217 ms 64 bytes from 192.168.0.1: icmp_seq=6 ttl=64 time=52.742 ms 64 bytes from 192.168.0.1: icmp_seq=7 ttl=64 time=53.176 ms 64 bytes from 192.168.0.1: icmp_seq=8 ttl=64 time=53.179 ms 64 bytes from 192.168.0.1: icmp_seq=9 ttl=64 time=53.027 ms 64 bytes from 192.168.0.1: icmp_seq=10 ttl=64 time=53.179 ms 64 bytes from 192.168.0.1: icmp_seq=11 ttl=64 time=52.623 ms 64 bytes from 192.168.0.1: icmp_seq=12 ttl=64 time=53.383 ms 64 bytes from 192.168.0.1: icmp_seq=13 ttl=64 time=52.906 ms 64 bytes from 192.168.0.1: icmp_seq=14 ttl=64 time=40.600 ms So tcp was getting push back = unrepresentative result if you want to test as if a queue on a remote router.