From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 D8B5D3B25D for ; Fri, 26 Aug 2016 04:14:54 -0400 (EDT) Received: by mail-wm0-x230.google.com with SMTP id i5so107102217wmg.0 for ; Fri, 26 Aug 2016 01:14:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=bVChTbmh8BREnz7cxkxvsGKGxaEZU/2cvlVANBT/A2A=; b=XdcgnC46Q3IprSx+s349yBSoa2V8tNKb/Pha295G1VA7ShYdegHOJ9cZdLJTcixBbu xf5tKIhnipgkGiQMysM8rQtvaRb+7hKhvZsV6VjQmDQCTXdfqB5hAEIDPhLq0jfAwfWP s3BS24JTrMYM3mymGPdT8ydgwkhuoxsqqz5KZvAjVlNHoPN+rDXSVhxA4ol+b3qMq5Iz ytBlsFQhHa/zBWruci6SlAhtcNFjtzBQmACYmV3n4aHDgFeQP5yEqMDn5jSpZCsDCNMI YuSjwjxs5UEn+0/+hasFA5Jes794un604cZCzPZ89VNvOiJAqd2d8C+WKWd/x0CJ4CO6 huWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=bVChTbmh8BREnz7cxkxvsGKGxaEZU/2cvlVANBT/A2A=; b=LWzz3T108Rh+BNLJC1t3/heS/ZZIwMEtZZ3kfJzQJzzLBc64QGBG7wKObiyWagt4ii AdgBo/qst2uSP4ZuWgyqbUj3jZTn8g9Tjv794yQkwhXM+HvcR/+deotpxAhpu2A96V/k SYYy6t5dEsUyUsoRMwj62HmT2ayRVkDrfUSdb+e2bJCAdYCIVv54yNdIfiexDpHnf0T5 j0lL6PVLdSaUz8H+KkhF06Ssjz+dqCTvWzcTgdgFFkSCKHbocwXjVS2itdJtfyV9JVkU GszInjz4fF/x2XX47D2jDaWY2Bg3eAfZtJaYBJSrqJrZhet97MkHwTYr0k85GljUMgZ7 dAEw== X-Gm-Message-State: AE9vXwMa3waGxXDL9GiLdzNxKa45v56yyPBqkRmnQCM8vIO3yevo0roDSruoNAgLusVWAA== X-Received: by 10.194.83.72 with SMTP id o8mr2224322wjy.187.1472199293844; Fri, 26 Aug 2016 01:14:53 -0700 (PDT) Received: from localhost.localdomain (host-89-243-172-136.as13285.net. [89.243.172.136]) by smtp.googlemail.com with ESMTPSA id a21sm19463136wma.10.2016.08.26.01.14.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Aug 2016 01:14:52 -0700 (PDT) To: "techicist@gmail.com" , cake@lists.bufferbloat.net References: <96AE5B3F-FDD6-455E-BB08-D4A162EC3F23@gmx.de> <3ed1004a-d688-11ec-c788-d8a456b22b34@gmail.com> From: Alan Jenkins Message-ID: Date: Fri, 26 Aug 2016 09:14:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------36730EA8E6E8D66BFAEADE57" Subject: Re: [Cake] Configuring cake for VDSL2 bridged connection 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: Fri, 26 Aug 2016 08:14:55 -0000 This is a multi-part message in MIME format. --------------36730EA8E6E8D66BFAEADE57 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 25/08/16 15:53, techicist@gmail.com wrote: > Sorry, what is flowblind? Yes, I am using cake :) flowblind gives you a single queue, who's maximum size is managed by (a modified) codel. It's useful for testing the codel. In the default (non- flowblind), each stream is randomly assigned to one of hundreds of queues. In fact cake magically avoids flows sharing queues until they have to. Then each queue is treated "fairly" w.r.t the bandwidth it can use. > So is that latency increase when uploading and downloading? And so I should > be aiming to achieve that as I slowly increase the bandwidth? That's the general idea, yes. For looking at latency statistics, FLENT also has a cumulative probability graph. If you'd rather have the numbers summarized for you, you might prefer Richard's netperfrunner. That's what I used to start with. It's not 100% the same but very close. (It's designed to only use ping for latency, which means it can use as close a target - on the other side of the ISP link - as possible. E.g. taken from "traceroute". I found that was useful for sensitivity). https://github.com/richb-hanover/CeroWrtScripts > > On 24 August 2016 at 20:49, Alan Jenkins > wrote: >> On 24/08/16 20:47, Alan Jenkins wrote: >> >> So you can read off (+calculate) overall throughput, in both directions. >> >> And it looks like your latency under load rises by only about 2ms. That's >> the sort of thing we're aiming for. >> >> Pure codel aims for 5ms, so I take it you're using fq_codel. >> >> /reads subject line >> >> or using standard cake, and not passing `flowblind` to disable the fair >> queuing >> >> And... yes >> >> (1500 * 8) / 4_000_000 = 0.003 >> >> It takes 3ms to transmit a full packet in the slower direction. So when >> it's busy, ping can be delayed on average by 1.5ms (while the current >> packet is transmitted). Something like that anyway. >> >> >> On 24/08/16 20:33, techicist@gmail.com wrote: >> >> Thanks for the reply. I understand now 😀 >> >> What can be taken from these graphs? I'm afraid I really am lost now. >> >> >> >> _______________________________________________ >> Cake mailing list >> Cake@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cake >> >> >> >> >> > > > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake --------------36730EA8E6E8D66BFAEADE57 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 25/08/16 15:53, techicist@gmail.com wrote:
Sorry, what is flowblind? Yes, I am using cake :)

flowblind gives you a single queue, who's maximum size is managed by (a modified) codel.  It's useful for testing the codel.

In the default (non- flowblind), each stream is randomly assigned to one of hundreds of queues.  In fact cake magically avoids flows sharing queues until they have to.  Then each queue is treated "fairly" w.r.t the bandwidth it can use.

So is that latency increase when uploading and downloading? And so I should
be aiming to achieve that as I slowly increase the bandwidth?

That's the general idea, yes.

For looking at latency statistics, FLENT also has a cumulative probability graph.

If you'd rather have the numbers summarized for you, you might prefer Richard's netperfrunner.  That's what I used to start with.  It's not 100% the same but very close.  (It's designed to only use ping for latency, which means it can use as close a target - on the other side of the ISP link - as possible.  E.g. taken from "traceroute".  I found that was useful for sensitivity).

https://github.com/richb-hanover/CeroWrtScripts


On 24 August 2016 at 20:49, Alan Jenkins <alan.christopher.jenkins@gmail.com

wrote:


      

        
On 24/08/16 20:47, Alan Jenkins wrote:

So you can read off (+calculate) overall throughput, in both directions.

And it looks like your latency under load rises by only about 2ms.  That's
the sort of thing we're aiming for.

Pure codel aims for 5ms, so I take it you're using fq_codel.

/reads subject line

or using standard cake, and not passing `flowblind` to disable the fair
queuing

And... yes

(1500 * 8) / 4_000_000 = 0.003

It takes 3ms to transmit a full packet in the slower direction. So when
it's busy, ping can be delayed on average by 1.5ms (while the current
packet is transmitted).  Something like that anyway.


On 24/08/16 20:33, techicist@gmail.com wrote:

Thanks for the reply. I understand now 😀

What can be taken from these graphs? I'm afraid I really am lost now.



_______________________________________________
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake







      

      

      

      

      

      
_______________________________________________
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake


    

    

  


--------------36730EA8E6E8D66BFAEADE57--