From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 0B8D93BA8E for ; Fri, 29 Jun 2018 06:56:28 -0400 (EDT) Received: by mail-io0-x233.google.com with SMTP id e15-v6so8097858iog.1 for ; Fri, 29 Jun 2018 03:56:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=3frIg9PyGbbXIYVCreblHr5k68je5tMhqeDl2tSVyeI=; b=VklxO3vCRCV6nwQ49Pm6s15Egtl1RUkJ+qRbhl8s4klozQDaQj9xpZ5mw/pzfGh92z QBw4jIub8XX4/9/XCnmYzSiRT/ep7ksH520CZZIJj9WP2lU3cowoJh2m7BQlqgo7YMZL XbQkjYnakn7nGuWfAVUikD6QY5F2KLIcbhO1W2IZxD0Qf3WkrkpYYThqx5LFsQSk63yd VlBo6owNJcNA7+68xT6mWR7I68/I4LzPm5ov5tuJzG4evfoTPJFfXSvCiT72g8G0iNPY gB4mB8hd4wTh7vmuEqexgvaIAgItT8QTT1iCSR9iLL2WqdAQ0i19WiEzADNkULvgBrYK sfcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=3frIg9PyGbbXIYVCreblHr5k68je5tMhqeDl2tSVyeI=; b=lIn22pMTAVGMARdv0qEo+kxsvKz4wI+xroHc9odJHVdHvi1HrEd9mpaMmFiFgQfYrE yZHMh1bJWql10c4Nrhed7xA7W94aO0JIUW9CON/s4N5fVV8sp4vKLB7wO7MNak+f6VY/ /Nz8kPFcPqQt0JutD7uNJmwUQc9DaSDoRQ84RvFiOA9qZPB/qnXZh2xatsfz46dlfG8B hSdm1sTEuvZOnrK5KFl/cLQ13jYXAdKG5bSlDHRm5QKVTReM5hL8UlGuFNeo6jYw9M4F +xRyKPeJNn/v9WQm4J7p+jyVEqAvudWyptbs2JeWFOhAHlSue75D1MDTS3qYuWEFVqyO W9nw== X-Gm-Message-State: APt69E33eWSUQNnskB0BlE0FqCWGKKg/bM2bP4vCmXI0HGrAIxf8JIHr YLrf3tQ6Q76QfLOIntHIxF1/YgVlRaMdto7V+Ndgxa96 X-Google-Smtp-Source: AAOMgpekJiB8nXTJ0lt/GDVux7w9jxT68eoWAsQmjzo9C411VOM4rnZXOqM1FT5lx5sdOdJVgfdDdYJvErH8cQQp6iI= X-Received: by 2002:a6b:5002:: with SMTP id e2-v6mr12164759iob.31.1530269788241; Fri, 29 Jun 2018 03:56:28 -0700 (PDT) MIME-Version: 1.0 From: =?UTF-8?Q?Jonas_M=C3=A5rtensson?= Date: Fri, 29 Jun 2018 12:56:17 +0200 Message-ID: To: bloat Content-Type: multipart/alternative; boundary="000000000000238543056fc5b380" Subject: [Bloat] powerboost and sqm X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 10:56:29 -0000 --000000000000238543056fc5b380 Content-Type: text/plain; charset="UTF-8" Hi, I have a 100/100 Mbit/s (advertised speed) connection over fiber (p2p, not PON). The actual link rate is 1 Gbit/s. My ISP seems to be using burst-tolerant shaping (similar to powerboost) as can be seen in this speedtest where the download rate is 300+ Mbit/s and the upload rate is around 150 Mbit/s for the first few seconds: http://www.dslreports.com/speedtest/35205027 It can be discussed why they are doing this but my questions are more related to the impact on the quality of my connection. The ISPs shaper used to introduce some bufferbloat, especially on the downlink, and I've been using sqm for a while to mitigate this. But recently they seem to have changed some configuration since the bufferbloat is now almost zero, except for some very short spikes which only show up when I check "Hi-Res BufferBloat" in test preferences (see speedtest above). When I enable sqm on my router with htb/fq_codel or cake the spikes disappear: htb/fq_codel: http://www.dslreports.com/speedtest/35205620 cake: http://www.dslreports.com/speedtest/35205718 Another difference is that the "Re-xmit" percentage (which I guess is related to packet loss) is much higher without sqm enabled. Intuitively this makes sense since temporarily allowing a higher rate should result in more buffer overflow when the rate is decreased. So, what do you think: - Are the latency spikes real? The fact that they disappear with sqm suggests so but what could cause such short spikes? Is it related to the powerboost? - Would you enable sqm on this connection? By doing so I miss out on the higher rate for the first few seconds. What are the actual downsides of not enabling sqm in this case? /Jonas --000000000000238543056fc5b380 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I have a 100/100 Mbit/s (advertised= speed) connection over fiber (p2p, not PON). The actual link rate is 1 Gbi= t/s. My ISP seems to be using burst-tolerant shaping (similar to powerboost= ) as can be seen in this speedtest where the download rate is 300+ Mbit/s a= nd the upload rate is around 150 Mbit/s for the first few seconds:


It can be discussed why they are doing this but my questions are more rel= ated to the impact on the quality of my connection. The ISPs shaper used to= introduce some bufferbloat, especially on the downlink, and I've been = using sqm for a while to mitigate this. But recently they seem to have chan= ged some configuration since the bufferbloat is now almost zero, except for= some very short spikes which only show up when I check "Hi-Res Buffer= Bloat" in test preferences (see speedtest above). When I enable sqm on= my router with htb/fq_codel or cake the spikes disappear:
cake:
<= div>
Another difference is that the "Re-xmit" perce= ntage (which I guess is related to packet loss) is much higher without sqm = enabled. Intuitively this makes sense since temporarily allowing a higher r= ate should result in more buffer overflow when the rate is decreased.
=

So, what do you think:

- Are t= he latency spikes real? The fact that they disappear with sqm suggests so b= ut what could cause such short spikes? Is it related to the powerboost?

- Would you enable sqm on this connection? By doing s= o I miss out on the higher rate for the first few seconds. What are the act= ual downsides of not enabling sqm in this case?

/J= onas
--000000000000238543056fc5b380--