From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (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 58E9B21F53B for ; Mon, 2 Nov 2015 12:38:14 -0800 (PST) Received: by wijp11 with SMTP id p11so59409929wij.0 for ; Mon, 02 Nov 2015 12:38:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=SK6wjSWUQm/5jpbiHJ9LHoUR07veSJpL66XHjT8q3pQ=; b=ODQh3yTWzUqqfgfECitAzkM6ImErC9aN1qU3c8XT35e766ixCzMCdpaF4I8e+RtCkG Ei1LyFN8AnhBV3AfKitAE/EQrKzpbOzpj8gRrZ5tlbxz1P/c+3LT0R8qsJZR0Fgc7NMx 8cO2UT58aqiLgyScG6TbgF3b7mJdzXQtCyx0zkfkHxnWSDPNX/j1biXN7kLNhO+33dsN JnHuHVFlv8tJbH+qhX/uflU56Y57LLJ9utFgeV8uIrXO7x0IHziBC1k82Kf0x9MiUWYW RzO+idUJ7gBetc2g9e71qP7PDml4AbOe+uArw0/yToP6vHiaWv22Ms+UNd5lopKIJ2b/ VONA== X-Received: by 10.194.243.102 with SMTP id wx6mr25434757wjc.68.1446496692982; Mon, 02 Nov 2015 12:38:12 -0800 (PST) Received: from volcano.localdomain (host-89-243-100-243.as13285.net. [89.243.100.243]) by smtp.googlemail.com with ESMTPSA id b12sm19990939wma.6.2015.11.02.12.38.12 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2015 12:38:12 -0800 (PST) To: Sebastian Moeller References: <2D22BEFF-B6B6-4348-B83E-3AB76F933BDF@gmx.de> From: Alan Jenkins Message-ID: <5637C9B3.4090704@gmail.com> Date: Mon, 2 Nov 2015 20:38:11 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "cake@lists.bufferbloat.net" Subject: Re: [Cake] cake target corner cases? 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: Mon, 02 Nov 2015 20:38:37 -0000 On 02/11/15 18:49, Sebastian Moeller wrote: > Hi Alan, Hi again Sebastian > On Nov 2, 2015, at 17:20 , Alan Jenkins wrote: > >> Actually I'm >> failing to measure any changes at all, even for mtu*1.5. I'm sure >> there's a real effect on buffering, if I had a less noisy way to >> measure it :(. I couldn't work out exactly what you wanted testing; >> if there's something more specific I could probably spend more time on >> it. > This is pretty much what I expected; the only interesting measurement left then is to disable this completely and see how a to small target affects latency under load… (I just wonder if this might be better measured with larger probe packets, say full MTU ICMP packets instead of small ones?) Good point! I should test with the "adaptation" feature entirely disabled, i.e. target=5ms. There should be a case where it decreases bandwidth. Setting the rate artificially low might be useful to make it easier to measure. Ah, the worst case for bandwidth should be a single stream, with tcp congestion control set to Reno (like non-server versions of Windows). Whereas my basic tests are multi-stream and use Linux' default Cubic. So that's probably what I was doing wrong. >> I agree with the reasoning for 1749 bytes. If you think mtu*1.5 is a >> good idea for SQM, I can't follow the logic, but it wouldn't bother me >> for fq_codel. > Oh, the 1.5 * 1749 is really just to be on the safe side, but until this setting makes a dent in at least one measurement, I guess I am not going to bother increasing this further; I will try to play with keeping interval at 20 to 10 times target though... I guess you want a similar setup to the 1s rtt test. Simulate a path delay of exactly 100ms, set a low rate, then look at the effect interval has on bandwidth. Regards Alan