From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id B6CF721F2ED for ; Sat, 7 Mar 2015 11:38:50 -0800 (PST) Received: by qcwb13 with SMTP id b13so20663461qcw.9 for ; Sat, 07 Mar 2015 11:38:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=uMhamxNUeCAiPC0FFfvYkhHxViUeN4AQjwk8Teo7U5k=; b=pRBprNmPrxv0j605pWfHpx6tw2dsHECZ5tpla90Ie+zbTzoEfo0loItpYFyO/v7NmP F+Y5rQqP3BvWQZLIOQe2e1/a7i+Xo9ZbWB6BqGk1mPfI+G72/23zFLnAbleBTfHKJ2tG s3o/RwiCvYF4L8lJDLEOE/hj9D+PqHZYPhwIM9pWuIH44aJDNULte7Xx+NX/cF6U88j/ n4urnI00Gy5o5kb7aPns+c6E9fB9e5oIB5bn7nvs+UAyKJLKZD3wfME5RA7dLhlTZYxQ ROxXVCK1lAJ0BNbVxgP6O50nFGhNgytP0W3jwyc1oWZc1sJaiJnqVcEnUdz8kIZpLVqV Qblw== MIME-Version: 1.0 X-Received: by 10.140.145.11 with SMTP id 11mr27814237qhr.19.1425757129255; Sat, 07 Mar 2015 11:38:49 -0800 (PST) Received: by 10.96.191.5 with HTTP; Sat, 7 Mar 2015 11:38:49 -0800 (PST) Date: Sat, 7 Mar 2015 19:38:49 +0000 Message-ID: From: Alan Jenkins To: Sebastian Moeller Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: cerowrt-devel Subject: [Cerowrt-devel] YA adsl result, in the UK, download already suprisingly well-shaped X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2015 19:39:19 -0000 snipped and CC'd for again for record On 05/03/2015, Sebastian Moeller wrote: > > On Mar 5, 2015, at 13:55 , Alan Jenkins > wrote: > >> On 05/03/2015, Sebastian Moeller wrote: >> >>>> I'm only shaping upload, because I can't measure any improvement >>>> from shaping download. [which seems kinda hopeful for the cause] >>> Interesting, in my case I need to shape both properly otherwise my >>> netperf-runner rrul test show too high latencies. >> Disregard, I suck. It's not "too high" for me, because I don't use >> anything like voip. But there is 10-20ms in it. >> >> Last time I gave up getting netperf to on debian (it just kept >> stalling out). I ran it on the router, maybe that screwed up the >> measurements. Now I have a Fedora to test with and sqm-scripts is >> definitely living up to the hype :) >> >> unshaped: >> >> 2015-03-05 12:16:06 Testing against netperf-eu.bufferbloat.net (ipv4) >> with 5 simultaneous sessions while pinging 89.243.96.1 (60 seconds in >> each direction) >> ............................................................. >> Download: 10.84 Mbps >> Latency: (in msec, 61 pings, 0.00% packet loss) >> Min: 21.100 >> 10pct: 23.700 >> Median: 34.700 >> Avg: 34.536 >> 90pct: 47.100 >> Max: 54.400 >> >> >> shaped 12500 (and I'm going to use 11500): >> >> Download: 10.14 Mbps >> Latency: (in msec, 61 pings, 0.00% packet loss) >> Min: 20.800 >> 10pct: 21.400 >> Median: 23.900 >> Avg: 24.010 >> 90pct: 26.100 >> Max: 29.900 > > If you install netperf-wrapper (https://github.com/tohojo/netperf-wrappe= r) > and run a test like: > date ; ping -c 10 netperf-eu.bufferbloat.net ; ./netperf-wrapper --ipv4 = -l > 300 -H netperf-eu.bufferbloat.net rrul -p all_scaled --disable-log -t > your_configuration_name_here > > you should be able to see even bigger improvements for shaped versus > unshaped (the rrul test will try to saturate both up and downlink, or use > /netperfrunner.sh -H netperf-eu.bufferbloat.net to simultaneously load up > and downlink without netperf-wrapper) I expect almost orders of magnitude > improvements ;) I'm being pedantic here, but you're wrong :). netperf-runner only shows 5-7ms difference. That might be part of why I struggled to measure it last time. Unshaped: 2015-03-07 19:13:14 Testing netperf-eu.bufferbloat.net (ipv4) with 4 streams down and up while pinging 89.243.96.1. Takes about 30 seconds. Download: 9.75 Mbps Upload: 0.38 Mbps Latency: (in msec, 32 pings, 0.00% packet loss) Min: 15.000 10pct: 15.700 Median: 30.700 Avg: 32.297 90pct: 45.400 Max: 67.600 Shaped at 11500 (+overhead set to atm, 40 bytes in gui) Download: 8.36 Mbps Upload: 0.41 Mbps Latency: (in msec, 30 pings, 0.00% packet loss) Min: 14.600 10pct: 15.100 Median: 25.400 Avg: 25.487 90pct: 38.600 Max: 41.100 >>>> Dunno what my ISP has deployed (UK ADSL, "thephone.coop" apparently >>>> reselling Talk Talk, presumably "LLU") but it gives me some hope :). >>> >>> If you truly have an adsl >> >> No FTTC here! > > What a pity, ATM encapsulation is awkward, it looked like a decent idea > while the telco networks seemed to converge on all ATM, but with the move= to > all ethernet, ATM is a relict a fossil that stubbornly refuses to go the = way > of the dodo=E2=80=A6 VDSL2=E2=80=99s PTM encapsulation is way saner and o= nly costs like 1% > overhead while ATM comes in at ~9% best case (and due to cell padding can= be > much worse) > >> >>> as compared to a more modern vdsl link, could I >>> convince you to try the link layer adjustments? If yes, please =E2=80= =9Choller=E2=80=9D; >>> I >>> have some basic tools to empirically figure out the per packet overhead >>> for >>> ATM-based adel links... >> >> I'm very willing to do that. > > Great, so the first step is to collect a large data set of ping probes. = The > attached shell script I like your example graph, it may take me a while to try though. Alan