From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (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 534803B2A3 for ; Mon, 18 Jan 2016 17:47:20 -0500 (EST) Received: by mail-ob0-x231.google.com with SMTP id py5so205011014obc.2 for ; Mon, 18 Jan 2016 14:47:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=AvJiDVLyx8P4xr5VPkS3rjIUBQUhy/BeLK0y4MxY2Xg=; b=02atpl757tyWwRzFWNlOk1RfqAA8kVYEBuXTw67aUp2v2dB+yCEx/53IL51EYUkaHf /ZObh0O4Uq4czo6zKIOef29eiwYFMbublQxOGC4cjbnlQNrtWEtUqc++Sv7RC7LTJHcq LG8DR+yN3szVcfLoolSBxZCV2ABGraVcg775FSNXNuSpEbB3xy6bWZbi/GBdq+Pyqn2t eF+UQbFS0zlu4wd+MO2UwUV+Mo1zO4PLq/TyYGfdIv9K2/pEDcaFsXL6yTg422B9EdYT 8/u5unl+DsVL1UuK6nlEY7UAcD/d12IXzIBxfb18l6YyOpxKQsakOTUarpmDAJuZ/qhF bYgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=AvJiDVLyx8P4xr5VPkS3rjIUBQUhy/BeLK0y4MxY2Xg=; b=XXdKxL/WNYKsYpB40ZcA4YsAmr65CLMKbADY5YbQQ4sAqSn9yu4m4Jyd4hWPlRjLnK 2IujTzAJQe3Zs6v/w8aL1R6ROaEQjJRxjNDZzGyWOzYgMXk41sKoqqvQi4zM3zCjiybG Eu5ruPZsxrZz6Xmia7DOTCvk1gJGteOYK/CPCbGp/4TNJr1SrT8CJM3U3l84S1uhdiEo A9Co42qzWHLFqZzEgsf2lB+g97jhnwfJQl7OV+VD5pIW4bNF9LQimV0whKUyCptejiho +4JNWq3+VfP0MLYpU4mgwrw7mSauEwEt8/30k+njeRN/GjN1I0FnwU64/tlrVGwKdgf5 i5ww== X-Gm-Message-State: ALoCoQkBsLMXnP4hMeh3tRVDhncCnHCQZUEkr13NqVIAlcr2AGlfAZHdfx7r7YhFzRkNqCIJzkVgwhPOHZpibwV7viETBfUwAg== MIME-Version: 1.0 X-Received: by 10.60.59.101 with SMTP id y5mr22004884oeq.61.1453157239600; Mon, 18 Jan 2016 14:47:19 -0800 (PST) Received: by 10.202.185.5 with HTTP; Mon, 18 Jan 2016 14:47:19 -0800 (PST) In-Reply-To: References: Date: Mon, 18 Jan 2016 14:47:19 -0800 Message-ID: From: Dave Taht To: cake@lists.bufferbloat.net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Cake] Fwd: longer rtt codel/cake testing with remote servers 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: Mon, 18 Jan 2016 22:47:20 -0000 This email, also: ---------- Forwarded message ---------- From: Dave Taht Date: Wed, Dec 23, 2015 at 6:30 AM Subject: Re: longer rtt codel/cake testing with remote servers To: cake@lists.bufferbloat.net also of good use is the new tc_iterate.sh and tc_iterate.c code which lets you track qdisc queue lengths, number of packets, outstanding bytes, and drops, on your machine AND on the remote router(s). If you want deeper insight into the actual queuing behavior, this is the code for it! Traditionally most aqm folk looked more at queue depth than at measured throughput.... There is a flent-flent-tc_iterate package for openwrt in ceropackages has a high precision version in c (you should use it on your own machine too - cd into your flent/misc dir and "make install" in there) after getting a root ssh key on the router, you can track the remote queue length statistic via: S=3Dflent-london.bufferbloat.net flent -l 60 -H $S -x -t noecn_pfifo_100mbit-wtf\ --test-parameter qdisc_stats_hosts=3Droot@your_router,root@your_rou= ter\ --test-parameter qdisc_stats_interfaces=3Dthe_interface,the_inbound_interface\ tc_iterate is actually capable of getting snapshots of the queue length dow= n below the 10ms level but flent is not. Last week's cake at 2mbit/384k http://snapon.cs.kau.se/~d/384k/batch-2015-12-21T140643/voip-rrul/384Kbit-0= 1/cake_bad_backlog.png vs my "bcake" variant: http://snapon.cs.kau.se/~d/384k/batch-2015-12-21T140643/voip-rrul/384Kbit-0= 1/bcake_saner_backlog.png be comforted at what happens to pie at these speeds, however: http://snapon.cs.kau.se/~d/384k/batch-2015-12-21T140643/voip-rrul/384Kbit-0= 1/becomfortedathowbadpieisthough.png There is perhaps insight to be gleaned by looking at drop patterns and so on, and the above dataset can be had at: https://kau.toke.dk/experiments/cake/batch-2015-12-21T140643.tar.gz A variety of RTTs and speeds are in: https://kau.toke.dk/experiments/cake/batch-2015-12-10T172606.tar.gz On Wed, Dec 23, 2015 at 3:08 PM, Dave Taht wrote: > I have long maintained a set of servers suitable for testing at a > range of RTTs, but did not publish them because I'd had no desire to > maintain them personally [1] for wide use, they are "in the cloud", so > I do not trust their network behavior not much past 100mbit, I > frequently used shapers on them merely to get interesting bandwidths > at varieties of RTTS, and they cost 10 bucks a month each which I have > sometimes needed for food. > > If people truly want to get a feel for how to modify codel without a > lab handy, these boxes would be good to test against - and have long > term flent data sets against, at typical home bandwidths, from your > home. The most basic multi-rtt tests are the rtt_fair tests, but the > rrul and tcp_upload/dlownload tests are also good for seeing the > interactions on long rtts... > > and it's always good to do occasionally do a test to, like, tokoyo and > wonder why tcp even works at all. > > I would like to find flent servers in finland, russia, australia/nz > spain, and elsewhere in the eu. [1] > > These machines are active subdomains of bufferbloat.net. > > netperf-west: defunct (was snapon) > netperf-east I do not know where this is actually > netperf-eu - this is toke's server somewhere > > flent-atlanta # georgia > flent-dallas # texas > flent-freemont # california > flent-london # england - this is also taht.net, at the moment > flent-newark # new jersey > flent-tokyo # japan > > [1] maintainer wanted. Also could use d-itg set up on them. Securely. > I also do not remember if they all have ecn enabled by default or not. > Several run the fq qdisc. I am in the progress of migrating several > to kvm from xen. > > I would argue for consistently using sch_fq on these servers with ecn > always enabled. I will check today. > > > Dave T=C3=A4ht > Let's go make home routers and wifi faster! With better software! > https://www.gofundme.com/savewifi