From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::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 DFA6221F2F5 for ; Thu, 19 Mar 2015 06:49:49 -0700 (PDT) Received: by wibdy8 with SMTP id dy8so118330932wib.0 for ; Thu, 19 Mar 2015 06:49:46 -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=W8IOWVaklGoij2nVaAqpnX2H+RtNfkDHxcclyVsZHdo=; b=VtaUZxRpENwDyQ7aK9l1YUV3i6RTqvasSQdGhw5QvrsxlXzIwAdLUHpWrH8FsLSs8A Y8qILRAYHNDzbpAkBbo2BNwqcVJoe1jgVA3dJBGM/bLKfSDEkSBbHSVa7Bjz7vlT4mCY /x5ItIZTQ2bGbT+N+mHs1n4LsV8I7tQVBhJctFMrl0yQ5X5xQz9HM3GWrFC5+B+IAZDY fnx8utZhAbTARIhWcObuO+dr2jkgVEvvd6fkFFywNMR5dLy0yMjdxS+HzFWhZ5sQTwgW Ynw9Ikqz1whAP4NrS97O/3HzmqgRNLRg7108TvpI0SKJoDWukPGVaSQFKEs/xh3/2tJv geEw== X-Received: by 10.180.20.177 with SMTP id o17mr16308984wie.66.1426772986571; Thu, 19 Mar 2015 06:49:46 -0700 (PDT) Received: from volcano.localdomain (host-92-11-216-112.as43234.net. [92.11.216.112]) by mx.google.com with ESMTPSA id ei3sm7626489wib.4.2015.03.19.06.49.45 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Mar 2015 06:49:45 -0700 (PDT) Message-ID: <550AD3F8.1000904@gmail.com> Date: Thu, 19 Mar 2015 13:49:44 +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 13:50:19 -0000 Hi Seb, I have one last suspicion on this topic On 19/03/15 08:29, Sebastian Moeller wrote: > 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. >>>> 2) SQM on ge00 shows better latency under load (LUL), the LUL >>>> increases for ~2*fq_codels target so 10ms, while SQM on pppeo-ge00 >>>> shows a LUL-increase (LULI) roughly twice as large or around 20ms. >>>> >>>> I have no idea why that is, if anybody has an idea please chime >>>> in. >> I saw the same, though with higher difference for egress rate. See first three files here: >> >> https://www.dropbox.com/sh/shwz0l7j4syp2ea/AAAxrhDkJ3TTy_Mq5KiFF3u2a?dl=0 >> >> [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 ;) Thinking about this, I remembered the issue that sqm de-priotises ICMP ping. (Back when I used betterspeedtest and netperf-runner, I did assume this would be an issue). I also notice that my test with eth1 (disabling classification) is the only one where UDP ping (including UDP EF) is visible for any time at all. (ok, pppoe-wan shows UDP BK, and it very clearly gets higher latency as I would expect). So I don't know if your results were clearer, but the results I showed so far should be treated as a measurement problem. >>> Once SQM on ge00 actually dives into the PPPoE packets and >>> applies/tests u32 filters the LUL increases to be almost identical to >>> pppoe-ge00’s if both ingress and egress classification are active and >>> do work. So it looks like the u32 filters I naively set up are quite >>> costly. Maybe there is a better way to set these up... >> Later you mentioned testing for coupling with egress rate. But you didn't test coupling with classification! > True, I was interesting in getting the 3-tier shaper to behave sanely, so I did not look at the 1-tier simplest.qos. > >> I switched from simple.qos to simplest.qos, and that achieved the lower latency on pppoe-wan. So I think your naive u32 filter setup wasn't the real problem. > Erm, but simplest.qos is not using the relevant tc filters, so the these could still account for the issue; that or some loss due to the 3 htb shapers...