From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 CA2383B25E for ; Sat, 27 Aug 2016 13:48:40 -0400 (EDT) Received: by mail-wm0-x234.google.com with SMTP id i5so34199708wmg.0 for ; Sat, 27 Aug 2016 10:48:40 -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=mD3TpofiUhrlmTlnhcoYj65ltVrYUpP1fspZkISZGjo=; b=JZ7T20rJVTD7jg95G8Hy//OILeyj+sxUH/YD7FZoifFVJ2k4lqxUrD7/prr56k6hle Qez6F3FoDx2k2Ax2HBxs75GD9yPN8AjyFfsA6cQNUqielmnMBixb0tviDNXljIqYeC1b eP7fLSFW9MOOf1lawKBX/60xL1XEr5YTbixwSjdrg4SePh9aZU4sESpJGEAqPtFGjtDz uNSiIgUmIvuECnvZkg1KWZMoWmlTIvB/5ryJDJ69gU6BG+gbXoE25Z1+YAy3OZZinhsH AI3aLiFrnh126stftQcFK8uRjHdS8D3RD7wxBU6czk9kiO20QoMMEogjHrl2fNHSuYNq egLQ== 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=mD3TpofiUhrlmTlnhcoYj65ltVrYUpP1fspZkISZGjo=; b=MJb7fFK9exzlJ8wdZ6lMhg6NShWMVJr4U6SqjcRJvH0oBkdVqvY0i6lzwAVZxBC34I wgIsm+bQohOPgq2yx70fkmZPNpBZTltaoUaTjqwnsPD9WJ9wdB+WEgIK/wJlaehE20Aw I85sEiaotbFd7aDn03gk+8vuyVvRy9duVS/3IwcJZXwbW+zpekdZJZXrWpvbJStSjmQL cha84KhmN+gu276mdmsqJtIAsuA1LCSLKVLoJaf+28jH6rHigHSOmaY2g3f/AK0MqoGM hQvlbU8OOhx2mo+1Her+k385TFcoUY8XobG0C5BM8KC767a4SIr4dRGZ5qcI40lGqcwC iwZA== X-Gm-Message-State: AE9vXwMxXTWfJ5O9dWmZNd/0UY8z0W3f/PUM22XYdWXBcxxzOusRByTOpE930MqszMj0Vg== X-Received: by 10.194.190.232 with SMTP id gt8mr9582656wjc.141.1472320119396; Sat, 27 Aug 2016 10:48:39 -0700 (PDT) Received: from localhost.localdomain (host-89-243-172-136.as13285.net. [89.243.172.136]) by smtp.googlemail.com with ESMTPSA id i3sm25601413wjd.31.2016.08.27.10.48.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 Aug 2016 10:48:37 -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> <23996FEA-F20C-4654-9A57-792927BCDC83@gmx.de> <7866b818-9e8d-6e0b-a223-690bba44b64b@gmail.com> From: Alan Jenkins Message-ID: Date: Sat, 27 Aug 2016 18:48:35 +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="------------4BED19CC0A5CFA2B4FABC8F2" 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: Sat, 27 Aug 2016 17:48:41 -0000 This is a multi-part message in MIME format. --------------4BED19CC0A5CFA2B4FABC8F2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 27/08/16 17:17, techicist@gmail.com wrote: > Here you go: > http://www.thinkbroadband.com/ping/share/9eeb4cf725e2ad98373e7f31c94c84f4.html ok. - Average latency is perfectly fine (for the points you mentioned) - Reading the docs for this tool ("How do I interpret my BQM graph?"), they suggest that spikes which show in yellow (the maximum, taken from 100 pings) but don't show in blue (average) "do not affect gaming". "The connection is good". (Also, your yellow spikes are shorter than some of the ones they show). http://www.thinkbroadband.com/faq/sections/bqm.html#313 I think they mean that 1% "late" packets will effectively be treated as lost packets for latency-sensitive apps, and such apps should be designed to handle low-level loss. Our Dave might call this a bit of a cop out though. - They're only to do with your bufferbloat / AQM, if they happen while the connection is used. If your connection is idle, you don't have any queue you could manage to decrease the queuing latency :). That said, the BQM docs suggest that if there was congestion at a larger shared link within your ISP, you would generally see an increase in the minimum latency (green). Because when the problem is caused by a large number users, the load will be averaged out and be much more consistent. -> They could be transient bufferbloat. Cake isn't running at the ISP end. If your connection was maliciously flooded >100% capacity, then a dumb ISP queue could fill, and delay the lucky packets that got through. Despite the cake on your end. Flooding the connection >100% is not that different to what a TCP connection does while starting up, in order to find what the current link capacity actually is. Browsing to a new web page typically involves starting a surprisingly large number of TCP connections. I run smokeping on a slower connection with fq_codel. I don't think my spikes are as high - I'd say +5-10ms to your +30-40. However my ISP's (download) queue management is relatively good (against web browsing). -> I don't think you've posted "bufferbloat" measurements for your ISP download queue, i.e. _without_ using rate-limiting on your router. That's my first cut. You could compare cake to traditional fq_codel (I think you might have to disable TCP offloads, in case you're effectively relying on Cake's peeling feature). I believe fq_codel is well characterized, whereas cake is more experimental. I don't expect that's the issue though. --------------4BED19CC0A5CFA2B4FABC8F2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 27/08/16 17:17, techicist@gmail.com wrote:
Here you go:
http://www.thinkbroadband.com/ping/share/9eeb4cf725e2ad98373e7f31c94c84f4.html

ok.

- Average latency is perfectly fine (for the points you mentioned)

- Reading the docs for this tool ("How do I interpret my BQM graph?"), they suggest that spikes which show in yellow (the maximum, taken from 100 pings) but don't show in blue (average) "do not affect gaming".  "The connection is good".  (Also, your yellow spikes are shorter than some of the ones they show).

http://www.thinkbroadband.com/faq/sections/bqm.html#313

I think they mean that 1% "late" packets will effectively be treated as lost packets for latency-sensitive apps, and such apps should be designed to handle low-level loss.  Our Dave might call this a bit of a cop out though.

- They're only to do with your bufferbloat / AQM, if they happen while the connection is used.  If your connection is idle, you don't have any queue you could manage to decrease the queuing latency :).

That said, the BQM docs suggest that if there was congestion at a larger shared link within your ISP, you would generally see an increase in the minimum latency (green).  Because when the problem is caused by a large number users, the load will be averaged out and be much more consistent.

-> They could be transient bufferbloat.

Cake isn't running at the ISP end.  If your connection was maliciously flooded >100% capacity, then a dumb ISP queue could fill, and delay the lucky packets that got through.  Despite the cake on your end.

Flooding the connection >100% is not that different to what a TCP connection does while starting up, in order to find what the current link capacity actually is.  Browsing to a new web page typically involves starting a surprisingly large number of TCP connections.

I run smokeping on a slower connection with fq_codel.  I don't think my spikes are as high - I'd say +5-10ms to your +30-40.  However my ISP's (download) queue management is relatively good (against web browsing).

 -> I don't think you've posted "bufferbloat" measurements for your ISP download queue, i.e. _without_ using rate-limiting on your router.

That's my first cut.

You could compare cake to traditional fq_codel (I think you might have to disable TCP offloads, in case you're effectively relying on Cake's peeling feature).  I believe fq_codel is well characterized, whereas cake is more experimental.  I don't expect that's the issue though.
--------------4BED19CC0A5CFA2B4FABC8F2--