From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 0EFAF21F543 for ; Wed, 25 Nov 2015 12:09:24 -0800 (PST) Received: from hms-beagle.home.lan ([87.164.160.171]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M7pI0-1aF4SX1hHE-00vPCn; Wed, 25 Nov 2015 21:09:21 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: Date: Wed, 25 Nov 2015 21:08:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <26A7C2F8-8306-4B71-9DFB-193ED5CAF4DF@gmx.de> References: <62B84B79-3092-480A-90D0-ED79955917D8@gmx.de> To: =?windows-1252?Q?Dave_T=E4ht?= X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:CDotpaGO8iIcFR3ERKfYzsgiu0sQOkM33qoDn7Py0Nm1HEk0nxt ounCcBtI+TJZfqLf8J1miQIqSKRK0ZeA9Ak3rMO3Rv3RDhPE6O9Przr19+pdf4dy2u2Oyr1 PTls3qQQYxs0zQTEShAowxZQLH2tDLpRP8mRhGHXbAkJw2Gf6CHoQ1lr0drRvcqYv7zSsaK ZWGoflj3WkRLbV/XZf1Jg== X-UI-Out-Filterresults: notjunk:1;V01:K0:ItW2i4jSOIs=:rKHRiZDCJIwWDXIFe3a8tt FzGlab9Dk5OjYI2GBN9vImN5ma4YJJY7muSBeIZS6QOPetL5WN8AmMn5qedxCNiRDXR/rUeDp NtOOjYbqwRrkrtYS6LQc1EDAOrrYTiiOQPGrzrLV2gDEWccFdM8bwuNdgk1Ufu5P6FB50NkBj DdvgzYe/HTipQJuCFtVAeT1zyzbjxhe6WuLGSZzT5rE4nONcIfUOtWx+IbEWCBswCwtrCPbc9 UajgapIU8nuVzdbSKR+CCJ4XCFkCD4NaLOj/9zjCQ12iIROSnKVLN44RFTQKohE9gvc5b5rBr s6klU2cP9dPMG5yWun83xtxgVflFGyGCxL0rOZgdnQz1cy4fEokDh0TOSLEGOQntn0ASnVzRf wJSzQzKuwf81VvyXU+uf7IXASI4Fc1IApXCEhoutVDVFBFEjRuqV51pfn8GweHKrn5YzafD4r hhLEl4jpzvGQNn1wWc+BWPVFjHidm/FQ+idDLxp+bL+VK9Y4qT/SRKUbNP5MJraLsqJzoy7Z1 tWUSTg8+BhdoQQQ1gUx9YnO7HodrQlgbwx1hxpTDO0SJikoPTWHQ9GFvaJAOCZFEMKJ2XzMiZ MKzQl5mhDYGjQKSrw5szN+2KAiYU+yparuKo6I+VGAOqVuwZf4u4ktUZCoTp4jkHKVLSAJiEZ 4rfmOTC81v+92Mzy3ulQj1YWUNGdNfFU6AQLVSR24fAO4mFeN4MuIZnyZi6LSbYxF5KqZ9bTr 9dWr5gSTWTmP74UjP3ihz000h1s4Coie7/mtHzPEGrPMEM4CbBIpnsoMldHzS7yI9BIkQTgdE uAkLYpq Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] basic cake X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 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, 25 Nov 2015 20:09:47 -0000 Hi Dave, On Nov 25, 2015, at 19:23 , Dave Taht wrote: > I am under the impression that the best case RTT that can be obtained > from dsl to the next hop gateway is in the 9ms range (no > interleaving) or about 18ms (with interleaving) - no matter the packet > size. Not sure about interleaving, if I can dig up something there I will = report it here. So on a modern VDSL2 line (rated 50/10Mbps) using G.INP retransmissions = on the downstream and interleaving (of unknown depth) on the upstream I = get: user@computer:~> /usr/sbin/traceroute gstatic.com traceroute to gstatic.com (173.194.112.55), 30 hops max, 60 byte packets 1 172.30.42.1 (172.30.42.1) 0.289 ms 0.279 ms 0.313 ms 2 87.186.224.243 (87.186.224.243) 8.715 ms 8.271 ms 8.254 ms 3 87.186.194.202 (87.186.194.202) 9.307 ms 9.319 ms 9.309 ms 4 217.239.48.202 (217.239.48.202) 11.146 ms 11.156 ms 11.157 ms 5 72.14.217.76 (72.14.217.76) 10.363 ms 10.588 ms 10.598 ms 6 209.85.254.108 (209.85.254.108) 12.143 ms 10.329 ms 17.548 ms 7 72.14.235.247 (72.14.235.247) 10.407 ms 10.205 ms 10.397 ms 8 fra07s28-in-f23.1e100.net (173.194.112.55) 10.359 ms 10.300 ms = 10.446 ms =20 but from ; ping -c 1000 87.186.194.202 (the first ICMP responder) I get = a summary: --- 87.186.194.202 ping statistics --- 1000 packets transmitted, 1000 received, 0% packet loss, time 1000700ms rtt min/avg/max/mdev =3D 6.896/9.313/23.189/1.292 ms So your 9ms is not too far off of my ~7ms best case result. I note that = supposedly BT uses G.INP on both down- and upstream (at least they were = reported to test that configuration) potentially reducing the RTT to = around < 7ms. I also note that XDSLs all seem to use a 4KHz symbol = clock, so 1/4ms is the theoretical lower bound just based on that... >=20 > It would be good to know what a basic ping does on a real dsl line, as > that uses nearly the smallest possible packet size. Using a ping with > a larger packet size, to compare. I have some data for a number of lines, but currently lack the = access to that data, I will try to compile it and send the data your = way. >=20 > In setting up a proper emulation the rtt should be in there, in > addition to the other calculations. >=20 > What sort of dsl lines are out there? (does anyone still have 384k? > 1mbit? on the uplink?) I believe even in many european countries and the rural US there = are plenty of lines at the outer reaches of ADSL connectivity, so some = lines only have 384k on the downlink and 64k on the uplink =85 Best Regards >=20 > Dave T=E4ht > Let's go make home routers and wifi faster! With better software! > https://www.gofundme.com/savewifi >=20 >=20 > On Wed, Nov 25, 2015 at 6:45 PM, Sebastian Moeller = wrote: >> Hi Dave, >>=20 >> On Nov 25, 2015, at 18:30 , Dave Taht wrote: >>=20 >>> On Wed, Nov 25, 2015 at 5:37 PM, Sebastian Moeller = wrote: >>>> Hi Dave, >>>>=20 >>>> On Nov 25, 2015, at 17:02 , Dave Taht wrote: >>>>=20 >>>>> Last night I went about removing nearly every unproven "feature" = that >>>>> has been added to cake since july, in part to establish a baseline = for >>>>> a performance comparison directly against sqm-scripts with >>>>> htb+fq_codel, on low end hardware, and in part, to be able to test >>>>> each newer feature >>>>> more fully on the testbed. >>>>=20 >>>> Oh, shiny, want have ;) So the plan is to assess the = performance cost of each of the individual features to allow a better = rationale to justify keeping or rejecting specific ones? Sounds like a = excellent idea. >>>=20 >>> pithy note here: >>>=20 >>> = https://github.com/dtaht/bcake/commit/4b9e6035bfa0160fa3fdaddcf1722c1cf924= afa9 >>=20 >> Oh, I am all for a) testing things properly before setting = defaults, b) actually expose toggles for important parameters (toggles = that better be followed, if I request "target 1 ms=94 I am fine with = cake whining/complaining in the log, I am not fine with cake just = (silently) doing what it thinks best; but we have been there before and = I failed to convince enough people on that approach, so that boat has = sailed and now instead of one cake with one toggle we have 2 cakes = without toggles ;) (note I do like the implement and test one change at = a time approach,)) >>=20 >>>=20 >>>>=20 >>>>>=20 >>>>> The very long list of commits is here, complete with pithy = comments, >>>>> in the separate repo. >>>>>=20 >>>>> https://github.com/dtaht/bcake/commits/master >>>>>=20 >>>>> I would like it if someone using a low end home router could = benchmark >>>>> this version of cake >>>>> against the mainline version. >>>>=20 >>>> Hrmmm, for that I would need to build my own firmwares, let=92s= see whether I am up for that=85 oh, will newcake still accept all of = tc-adv=92s command line arguments (and simply ignore them?) >>>=20 >>> I am keeping the api for now. >>=20 >> Great that will make comparative testing easier... >>=20 >>>=20 >>> I note that first up is cake besteffort flowblind 384k and cake >>> besteffort flowblind 1mbit, with 5ms target. >>=20 >> My hypothesis is that cake will stay longer in the drop state = than required, effectively sacrificing more bandwidth (per flow) than = necessary to reach the sojourn target. Cake=92s approach to dequeue = nicely time based should make sure packet sojourn time will actually be = a good correlate at what happens at the real bottle-neck. Now I am = curious what the results will be? So to risk a prediction, without the = target adjustment or the 1 packet is always allowed shortcut original = codel took, cake will sacrifice more bandwidth reducing effective = throughput. I have no good idea for latency of un-related sparse flows, = but would assume they will suffer a bit as well (entering drop state = immediately?). Anyway looking forward to the results. >>=20 >>>=20 >>> While we have established that "bad things happen", I really don't >>> know what they look like. We have a lot of tools >>> for generating traffic, but no pictures of what actually happens. >>=20 >> Yes, +1 for better/more visualizations. >>=20 >>>=20 >>> But you might want to skip this round of testing before we establish >>> this baseline and move on. >>=20 >> Given the sorry state of my home network, I probably should = wait a bit ;). >>=20 >> Best Regards >> Sebastian >>=20 >>>=20 >>>>=20 >>>>>=20 >>>>> My plan, such as it is, is to keep simplifying, and testing. I = still >>>>> don't get the new hashing >>>>> API.... >>>>>=20 >>>>> This reduction effort was fruitful in that I found yet another way = to >>>>> reuse "now"=85 >>>>=20 >>>> As long as there are few enough cycles between the uses that = sounds wonderful, otherwise now degrades to once ;) >>>>=20 >>>>> fixed one bug, maybe spotted another... >>>>>=20 >>>>> Toke has been busy with flent, which has gained a really abusive = 1000 >>>>> tcp flows test, >>>>=20 >>>> bidirectional by any chance? Sort of the full internet = simulator for home-routers? >>>>=20 >>>>=20 >>>> Best Regards >>>> Sebastian >>>>=20 >>>>> and >>>>> the ability to parse qdisc statistics, so long as you tell flent = where >>>>> to get them from: >>>>>=20 >>>>>=20 >>>>> --test-parameter qdisc_stats_hosts=3Dlocalhost\ >>>>> --test-parameter qdisc_stats_interfaces=3D$IFACE\ >>>>>=20 >>>>> http://snapon.cs.kau.se/~d/newcake/t >>>>>=20 >>>>>=20 >>>>> -- >>>>> Dave T=E4ht >>>>> Let's go make home routers and wifi faster! With better software! >>>>> https://www.gofundme.com/savewifi >>>>> _______________________________________________ >>>>> Cake mailing list >>>>> Cake@lists.bufferbloat.net >>>>> https://lists.bufferbloat.net/listinfo/cake >>>>=20 >>=20