From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (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 2150221F184 for ; Thu, 19 Mar 2015 02:42:46 -0700 (PDT) Received: by wggv3 with SMTP id v3so57384446wgg.1 for ; Thu, 19 Mar 2015 02:42:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=K47IHhB/OEcVaCxf8XH9Q+dS0BqWhBosDyf0B4QPjR4=; b=X1fGGS6OHAsdexsht3WNPkqULNdwGIJhy4pCmXTRP0E+l4vuPgfRPNV/vpguG6gZXT wpDqYx0qxQCvvyLQ3Ng8EBIelwLAmPl3HzhdP1wlRyBb8gXSdx3O98Ep0oQPhzgQOdan rrv/9/l4cnmzkwOhLBW0RtCIuWYg8F6C45SbX9gH+86vOe/t1sBNb8VvdL5fx9qprNHV n10yLvxMqtb2lipcmgy9I9HuK/3bI1iiINKhm01Y4Eydo1DMHxfzfnc8VmC9pS36740i mqZUet9RjcMSXYOxe5tKve781G2tCP3Z+Wg71gvttAzdZ+a8S+TRV8AEdbVkqT34haU/ USgg== X-Received: by 10.194.157.68 with SMTP id wk4mr31606094wjb.130.1426758164484; Thu, 19 Mar 2015 02:42:44 -0700 (PDT) Received: from volcano.localdomain (host-92-11-216-112.as43234.net. [92.11.216.112]) by mx.google.com with ESMTPSA id dn7sm6732358wid.12.2015.03.19.02.42.43 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Mar 2015 02:42:43 -0700 (PDT) Message-ID: <550A9A12.1040007@gmail.com> Date: Thu, 19 Mar 2015 09:42:42 +0000 From: Alan Jenkins User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Sebastian Moeller References: <1895D16A-1B0F-48C7-B4B5-6FC84CA92F43@gmx.de> <5509F8B1.6090608@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: cerowrt-devel Subject: Re: [Cerowrt-devel] SQM and PPPoE, more questions than answers... 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: Thu, 19 Mar 2015 09:43:15 -0000 On 19/03/15 08:29, Sebastian Moeller wrote: > Hi Alan, > > > On Mar 18, 2015, at 23:14 , Alan Jenkins wrote: > >> Hi Seb >> >> I tested shaping on eth1 vs pppoe-wan, as it applies to ADSL. (On Barrier Breaker + sqm-scripts). Maybe this is going back a bit & no longer interesting to read. But it seemed suspicious & interesting enough that I wanted to test it. >> >> My conclusion was 1) I should stick with pppoe-wan, > Not a bad decision, especially given the recent changes to SQM to make it survive transient pppoe-interface disappearances. Before those changes the beauty of shaping on the ethernet device was that pppoe could come and go, but SQM stayed active and working. But due to your help this problem seems fixed now. I'd say your help and my selfish prodding :). >> 2) the question really means do you want to disable classification >> 3) I personally want to preserve the upload bandwidth and accept slightly higher latency. > My question still is, is the bandwidth sacrifice really necessary or is this test just showing a corner case in simple.qos that can be fixed. I currently lack enough time to tackle this effectively. Yep ok (no complaint). >> [netperf-wrapper noob puzzle: most of the ping lines vanish part-way through. Maybe I failed it somehow.] > This is not your fault, the UDP probes net-perf wrapper uses do not accept packet loss, once a packet (I believe) is lost the stream stops. This is not ideal, but it gives a good quick indicator of packet loss for sparse streams ;) Heh, thanks. >> My tests look like simplest.qos gives a lower egress rate, but not as low as eth1. (Like 20% vs 40%). So that's also similar. >> >>>> So the current choice is either to accept a noticeable increase in >>>> LULI (but note some years ago even an average of 20ms most likely >>>> was rare in the real life) or a equally noticeable decrease in >>>> egress bandwidth… >>> I guess it is back to the drawing board to figure out how to speed up >>> the classification… and then revisit the PPPoE question again… >> so maybe the question is actually classification v.s. not? >> >> + IMO slow asymmetric links don't want to lose more upload bandwidth than necessary. And I'm losing a *lot* in this test. >> + As you say, having only 20ms excess would still be a big improvement. We could ignore the bait of 10ms right now. >> >> vs >> >> - lowest latency I've seen testing my link. almost suspicious. looks close to 10ms average, when the dsl rate puts a lower bound of 7ms on the average. > Curious: what is your link speed? dsl sync 912k up shaped at 850 fq_codel auto target says => 14.5ms <= MTU time is 912kbps / (1500*8)b = 0.0132s so if the link is filled with MTU packets, there's a hard 7ms lower bound, on average icmp ping increase v.s. an empty link and the same logic says on achieving that average, you have >= 7ms jitter (or 6.5ms, but since my download rate is about 10x better, 6.5 + 0.65 ~= 7). >> - fq_codel honestly works miracles already. classification is the knob people had to use previously, who had enough time to twiddle it. >> - on netperf-runner plots the "banding" doesn't look brilliant on slow links anyway > On slow links I always used to add “-s 0.8” with higher numbers the slower the link to increase the temporal averaging window, this reduces accuracy of the display for the downlink, but at least allows better understanding of the uplink. I always wanted to see whether I could treach netperf-wrapper to allow larger averaging windows after measurements, just for display purposes, but I am a total beginner with python... > >>>> P.S.: It turns out, at least on my link, that for shaping on >>>> pppoe-ge00 the kernel does not account for any header >>>> automatically, so I need to specify a per-packet-overhead (PPOH) of >>>> 40 bytes (an an ADSL2+ link with ATM linklayer); when shaping on >>>> ge00 however (with the kernel still terminating the PPPoE link to >>>> my ISP) I only need to specify an PPOH of 26 as the kernel already >>>> adds the 14 bytes for the ethernet header… > Please disregard this part, I need to implement better tests for this instead on only relaying on netperf-wrapper results ;) . Apart from kernel code, I did wonder how this was tested :). Thanks again Alan